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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionality and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in document 
TS 32.240 [1], which provides an umbrella for other charging management documents that specify 

- the content of the CDRs per domain and subsystem (offline charging), 

- the content of real-time charging events per domain / subsystem (online charging); 

- the functionality of online and offline charging for those domains and subsystems; 

- the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or charging 
events) 

The complete document structure for these TSs is defined in TS 32.240 [1]. 

The present document specifies the Offline and Online Charging description for the IP Multimedia Subsystem (IMS), 
based on the functional descriptions of the IMS in 3GPP TS 23.228 [200]. This charging description includes the offline 
and online charging architecture and scenarios specific to IMS, as well as the mapping of common 3GPP charging 
architecture specified in TS 32.240 [1] onto IMS. It further specifies the structure and content of the CDRs for offline 
charging, and the charging events for online charging. The present document is related to other 3GPP charging TSs as 
follows: 

■ The common 3GPP charging architecture is specified in TS 32.240 [1]; 

■ The parameters, abstract syntax and encoding rules for these CDR types are specified in TS 32.298 [51]. 

■ A transaction based mechanism for the transfer of CDRs within the network is specified in TS 32.295 [54]. 

■ The file based mechanism used to transfer the CDRs from the network to the operator"s billing domain (e.g. 
the billing system or a mediation device) is specified in TS 32.297 [52]. 

■ The 3GPP Diameter application that is used for IMS offline and online charging is specified in TS 32.299 [50]. 

All references, abbreviations, definitions, descriptions, principles and requirements, used in the present document, that 
are common across 3GPP TSs, are defined in the 3GPP Vocabulary, TR 21.905 [100]. Those that are common across 
charging management in GSM/UMTS domains or subsystems are provided in the umbrella document TS 32.240 [1] and 
are copied into clause 3 of the present document for ease of reading. Finally, those items that are specific to the present 
document are defined exclusively in the present document. 



References 



The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

a) The 3GPP charging specifications 

[1] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging 

architecture and principles". 

[2]-[9] Void. 
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[10] 3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched 

(CS) domain charging". 

[11] 3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched 

(PS) domain charging". 

[12] 3GPP TS 32.252: "Telecommunication management; Charging management; Wireless Local Area 

Network (WLAN) charging". 

[13]-[29] Void. 

[30] 3GPP TS 32.270: "Telecommunication management; Charging management; Multimedia 

Messaging Service (MMS) charging". 

[31] 3GPP TS 32.271: "Telecommunication management; Charging management; Location Services 

(LCS) charging". 

[32]-[49] Void. 

[50] 3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging 

application 

[51] 3GPP TS 32.298: "Telecommunication management; Charging management; Charging Data 

Record (CDR) parameter description 

[52] 3GPP TS 32.297: "Telecommunication management; Charging management; Charging Data 

Records (CDR) file format and transfer 

[53] 3GPP TS 32.296: "Telecommunication management; Charging management; Online Charging 

System (OCS) applications and interfaces". 

[54] 3GPP TS 32.295: "Telecommunication management; Charging management; Charging Data 

Record (CDR) transfer". 

[55]-[99] Void. 

b) Common 3GPP specifications 

[100] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[101] 3GPP TS 22.101: "Service aspects; Service Principles". 

[102] 3GPP TS 22.1 15 "Service aspects; Charging and BilHng". 

[103] 3GPP TS 23.002: "Network Architecture". 

[104] 3GPP TS 23.003: "Numbering, addressing and identification". 

[105] 3GPP TS 27.001: "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 

c) other Domain and Service specific 3GPP / ETSI specifications 
[200] 3GPP TS 22.228 : "IMS Stage 1 " . 

[20 1 ] 3GPP TS 23 .228 : " Functional stage 2 description of IMS " . 

[202] 3GPP TS 24.228: 'Signalling flows for the IP multimedia call control based on SIP and SDP, Stage 

3' 

[203] 3GPP TS 23.218: IP Multimedia (IM) session handling; IM call model; Stage 2' 

[204] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[205]-[299] Void. 

d) Relevant ITU Recommendations 
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[300] ITU-T Recommendation D.93: "Charging and accounting in the international land mobile 

telephone service (provided via cellular radio systems)". 

[301]-[309] Void. 

[310] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

[311]-[329] Void. 

[330] ITU-T Recommendation Q.767: "Application of the ISDN user part of CCITT signalling System 

No. 7 for international ISDN interconnections". 

[331]-[349] Void. 

[350] ITU-T Recommendation X.25: "Interface between Data Terminal Equipment (DTE) and Data 

Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to 
public data networks by dedicated circuit". 

[351] ITU-T Recommendation X. 1 2 1 : "International numbering plan for public data networks" . 

[351]-[399] Void. 

e) Relevant IETF RFCs 

[400] IETF RFC 959 (1985): "File Transfer Protocol". 

[401] IETF RFC 3588 (2003): 'diameter base protocol' 

[402] IETF Internet-Draft 'Diameter Credit Control Application' 

[403] IETF RFC 2806: "URLs for Telephone Calls" . 

[404] IETF RFC 3261: "SIP: Session Initiation Protocol ". 

[405] IETF RFC 2486: "The Network Access Identifier". 

[406] RFC 3455 (January 2003): "Private Header (P-Header) Extensions to the Session Initiation 

Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)". 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [50], 3GPP 
TS 32.240 [1], and the following apply: 

billing: function whereby CDRs generated by the charging function are transformed into bills requiring payment. 

Billing Domain: Part of the operator network, which is outside the core network, that receives and processes charging 
information from the core network charging functions. It includes functions that can provide billing mediation and 
billing end applications. 

CDR field Categories: the CDR fields are defined in the present document. They are divided into the following 
categories: 

• Mandatory: field that shall be present in the CDR. 

• Conditional: field that shall be present in a CDR if certain conditions are met. 

• Operator Provisionable: Mandatory: A field that operators have provisioned to be included in the CDR for all 
conditions. 
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• Operator Provisionable: Conditional: A field that operators have provisioned to be included in the CDR if 
certain conditions are met. 

chargeable event: activity utilizing telecommunications network infrastructure and related services for: 

• user to user communication (e.g. a single call, a data communication session or a short message); or 

• user to network communication (e.g. service profile administration); or 

• inter-network communication (e.g. transferring calls, signalling, or short messages); or 

• mobility (e.g. roaming or inter-system handover); and 

• that the network operator wants to charge for. 

charged party: user involved in a chargeable event who has to pay parts or the whole charges of the chargeable event, 
or a third party paying the charges caused by one or all users involved in the chargeable event, or a network operator. 

charging: function whereby information related to a chargeable event is formatted and transferred in order to make it 
possible to determine usage for which the charged party may be billed. 

Charging Data Record (CDR): record generated by a network element for the purpose of billing a subscriber for the 
provided service. It includes fields identifying the user, the session and the network elements as well as information on 
the network resources and services used to support a subscriber session. In the traditional circuit domain, CDR has been 
used to denote "Call Detail Record", which is subsumed by "Charging Data Record" hereafter. 

charging function: entity inside the core network domain, subsystem or service that is involved in charging for that 
domain, subsystem or service. 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required 

partial CDR: CDR that provides information on part of a subscriber session. A long session may be covered by several 
partial CDRs. Two formats are considered for Partial CDRs. One that contains all of the necessary fields; the second has 
a reduced format. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ABNF Augmented Backus-Naur Form 

ACA Accounting Answer 

ACR Accounting Request 

AS Application Server 

AVP Attribute Value Pair 

B2BUA Back-to-Back User Agent 

BGCF Breakout Gateway Control Function 

BS BilHng System 

CCA Credit Control Answer 

CCF Charging Collection Function 

CCR Credit Control Request 

CDF Charging Data Function 

CDR Charging Data Record 

CGF Charging Gateway Function 

CPCF Content Provider Charging Function 

ECF Event Charging Function 

ECUR Event Charging with Unit Reservation 

CSCF Call Session Control Function (I-Interrogating; P-Proxy; and S-Serving) 

lEC Immediate Event Charging 

IMS IP Multimedia Subsystem 

IMS-GWF IMS Gateway Function 
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ISC IMS Service Control 

MGCF Media Gateway Control Function 

MRFC Media Resource Function Controller 

MRFP Multimedia Resource Function Processor 

OCS Online Charging System 

SCCF Subscriber Content Charging Function 

SCUR Session Charging with Unit Reservation 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UA User Agent 

UE User Equipment 



3.3 Symbols 



For the purposes of the present document, the following symbols apply: 



Bi 
Ga 
Rf 
Ro 



Reference point for the CDR file transfer from the IMS CGF to the BD. 

Reference point for CDR transfer between a CDF and CGF. 

Offline Charging Reference Point between an IMS Network Entity or an AS and CDF 

Online Charging Reference Point between an AS or MRFC and IMS-GWF and the OCS 



4 Architecture Considerations 

4.1 High level IP Multimedia Subsystem (IMS) architecture 

The following figure depicts the logical IMS architecture, as described in 3GPP TS 23.002 [103] 
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Figure : IMS logical architecture 
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4.2 IMS offline charging architecture 

The architecture for IMS offline charging is described in the following figure. The Rf interface is described in clause 
6.1.1 and Bi in clause 6.1.2. 
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Figure : IMS offline charging architecture 

NOTE: The combination of the CDF/CGF coiTesponds to the 3GPP Rel-5 CCF. 

4.3 IMS online charging architecture 

The architecture for IMS online charging is described in the following figure. The Ro interface is described in clause 
6.2 and ISC in TS 23.228 [201]. 
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Figure: IMS online charging Architecture 
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5 Charging Principles 

5.1 IIVIS Charging Principles 

The AS and MRFC are able to distinguish whether to apply offline or online charging, i.e. whether to send charging 
information over the Rf interface to the CDF or over the Ro interface to the OCS, which includes ECF and SCF as 
described in chapter 4.3 (or to use both). The decision of which interface to use is based on the information (CDF and/or 
OCS address) the AS/MRFC receive in the SIP signalling and the system configuration as provisioned by the operator. 
If the AS/MRFC only receive the CDF address and do not receive an OCS address then they use only the Rf interface. 
If only the OCS address was provided then they use only the Ro interface. In cases where both CDF and OCS addresses 
are provided it is possible to use both interfaces simultaneously. 

However, operators may overrule the addresses received via the SIP signalling and use their own configured rules 
instead. Operators may configure locally on the AS/MRFC an OCS and/or CDF address. The choice of whether the 
IMS network elements use locally configured addresses or the addresses received by SIP signalling, and the decision on 
which interface(s) to use, is left for operator configuration. 

All other IMS network elements (S-CSCF, P-CSCF, I-CSCF, BGCF and MGCF) apply offline charging via the Rf 
interface using the CDF address as received via SIP signalling or the locally configured CDF address in the IMS 
network element. The S-CSCF supports online charging using: 

the ISC interface, i.e. if the application server addressed over ISC is the IMS Gateway Function, or 

the Ro interface directly instead of the ISC, if the IMS Gateway Function is integrated within the S-CSCF. 

The offline and online charging function addresses transferred in SIP signalling are encoded in the P-Charging- 
Function- Addresses as defined in TS 24.229 [204] and RFC 3455 [406]. The P-Charging-Function- Addresses header 
contains the following parameters: CCF (i.e. CDF) and ECF (i.e. OCS). 

5.1 .2 IMS Charging Correlation 

5.1 .2.1 Basic Principles for IMS Domain Correlation 

The IMS charging correlation information is encoded in the SIP P-Charging- Vector header as defined in the following 
sub clauses. The P-Charging- Vector header contains the following parameters: ICID, access network charging identifier 
and lOI. 

General correlation mechanisms are defined in TS 32.240 [1], and further details about the usage of P-Charging- Vector 
are defined in TS 24.229 [204] and RFC 3455 [406]. 

5.1 .2.2 IMS Charging Identifier (ICID) 

The IMS domain correlation is based on IMS Charging Identifier (ICID) shared between IMS network elements 
involved with the same session/transaction. With ICID it is possible to correlate session/transaction related charging 
data generated in different IMS elements (i.e. x-CSCFs, ASs"). The ICID is included in all SIP methods, if the P- 
Charging- Vector header is present, and transferred through originating and terminating side nodes, except to UE. 

The value of the ICID parameter is identical with the 'icid-value' parameter defined in TS 24.229 [204]. The 'icid-value' 
is a mandatory part of the P-Charging- Vector and coded as a text-based UTF-8 charset (as are all SIP messages). For 
further information regarding the composition and usage of the P-Charging- Vector refer to [204] and RFC 3455 [406]. 

The ICID value is globally unique across all 3GPP IMS networks for a time period of at least one month, implying that 
neither the node that generated this ICID nor any other IMS network element reuse this value before the uniqueness 
period expires. The one month minimum uniqueness period counts from the time of release of the ICID, i.e. the ICID 
value no longer being used. This can be achieved by using node specific information, e.g. high-granularity time 
information and / or topology / location information. The exact method how to achieve the uniqueness requirement is 
an implementation issue. 
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At each SIP session unrelated method, both initial and subsequent (e.g., REGISTER, NOTIFY, MESSAGE etc.), a new, 
session unrelated ICID is generated at the first IMS network element that processes the method. This ICID value is 
contained in the SIP request and response of that SIP transaction and must be valid for the duration of the transaction. 

At each SIP session establishment a new, session specific ICID is generated at the first IMS network element that 
processes the session-initiating SIP INVITE message. This ICID is then used in all subsequent SIP messages for that 
session (e.g., 200 OK, (re-)INVITE, BYE etc.) until the session is terminated. 

5.1 .2.3 Access network charging identifier 

The access network charging identifier is the media flow level data shared among the IMS network elements for one 
side of the session (either the originating or terminating side). This information is used to correlate the access network 
charging data with the IMS charging data. GPRS charging information (GGSN identifier and PDP context information) 
is an example of access network charging identifier. The access network charging identifier is populated in the P- 
Charging-Vector using the access-network-charging-info parameter. For further information regarding the composition 
and usage of the access-network-charging-info parameter refer to TS 24.229[204] and RFC 3455 [406]. 

5.1 .2.4 Inter Operator Identifier (101) 

The lOI identifies both originating and terminating networks involved in a session/transaction. The lOI may be 
generated from each side of session/transaction to identify the home networks associated with each side. The orig-ioi 
and term-ioi parameters of P-Charging- Vector represent the originating and terminating operator identifiers. For further 
information regarding the composition and usage of the orig-ioi and term-ioi parameters refer to TS 24.229[204] and 
RFC 3455 [406]. 

5.1 .2.5 Application Charging Identifier (ACID) 

< If ACID will be accepted, the same kind of description than for ICID should be included here, i.e. more general than 
in Annex B > 

5.2 IMS Offline Charging Principles 
5.2.1 Basic Principles 

The offline charging functionality is based on the IMS network nodes reporting accounting information upon reception 
of various SIP methods or ISUP messages, as most of the accounting relevant information is contained in these 
messages. This reporting is achieved by sending Diameter Accounting Requests (ACR) [Start, Interim, Stop and Event] 
from the IMS network elements to the CDF. 

The Diameter client uses ACR Start, Interim and Stop in procedures related to successful SIP sessions. It uses ACR 
Events for unsuccessful SIP sessions and for session unrelated procedures. Further details are specified in the tables 
below and in clause 5.2.2. 

It is operator configurable in the nodes for which SIP method or ISUP messages an Accounting Request is sent, with the 
exception that if accounting information is collected for sessions the ACR [Start] and ACR [Stop] messages are 
mandatory according to the tables below. The table below describes all possible ACRs that might be sent from a 
P-CSCF, I-CSCF, S-CSCF, MGCF or BGCF. A list of node specific ACRs, along with the AVPs to be included are 
detailed in TS 32.299 [50]. 

The ACRs to be sent from a MRFC are described in table 5.2. 

In the tables below, the terms "configurable" implies that operators may enable or disable the generation of an ACR 
message by the IMS node in response to a particular "Triggering SIP Method /ISUP Message". However, for those table 
entries marked with *, the operator can enable or disable the ACR message based on whether or not the SIP (Re) Invite 
message that is replied to by the "Triggering SIP Method /ISUP Message" carried piggybacked user data. 

Table : Accounting Request Messages Triggered by SIP Methods or ISUP Messages 
for all IMS nodes except for MRFC and AS 
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Diameter 
lUlessage 


Triggering SIP Method /ISUP Message 


Mandatory/ 
Configurable 


ACR [Start] 


SIP 200 OK acknowledging an initial SIP INVITE 


Mandatory 


ISUP:ANM (applicable for the MGCF) 


Mandatory 


ACR [Interim] 


SIP 200 OK acknowledging a SIP 

RE-INVITE or SIP UPDATE [e.g. change in media components] 


Configurable 


Expiration of AVP [Acct-lnterJm-lnterval] 


Configurable 


ACR [Stop] 


SIP BYE message (both normal and abnormal session termination cases) 


Mandatory 


ISUP:REL (applicable for the MGCF) 


Mandatory 


ACR [Event] 


SIP 200 OK acknowledging non-session related SIP messages, which are: 
SIP NOTIFY 
SIP MESSAGE 
SIP REGISTER 
SIP SUBSCRIBE 


Configurable 
Configurable 
Configurable 
Configurable 


SIP REFER 


Configurable 


SIP PUBLISH 


Configurable 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP session set-up 


Configurable * 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated 
procedure 


Configurable * 


SIP CANCEL, indicating abortion of a SIP session set-up 


Configurable * 


l-CSCF completing a Cx Query that was issued in response to a SIP INVITE 


Configurable 


NOTE: SIP SUBSCRIBE with the field "Expires" set to means unsubscribe. SIP REGISTER with its "Expires" 
header field or "Expires" parameter equal to means Deregistration (see 3GPP TS 24.229 [204]). 



Table : Accounting Request Messages Triggered by SIP Methods for the MRFC 



Diameter 
Message 


Trigger 


Mandatory/ 
Configurable 


ACR [Start] 


SIP 200 OK acknowledging an SIP INVITE for initiating a multimedia ad hoc 
conferencing session 


Mandatory 


ACR [Interim] 


SIP ACK acknowledging a SIP INVITE to connect an UE to the conferencing session 


Configurable 


Expiration of AVP [Acct-lnterim-lnterval] 


Configurable 


ACR [Stop] 


SIP BYE message 


Mandatory 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing 
session 


Mandatory 



ASs support all four ACR types (Start/Interim/Stop/Event). The use of ACR Start, Interim and Stop (Session Charging) 
versus ACR Event (Event Charging) depends on the services provided by the application server. Example flows for an 
AS employing Event Charging and an AS using Session Charging are shown in clause 5.2.2.1. 

The ability of SIP methods not listed in tables 5.1 and 5.2 to trigger ACRs is for further study. 
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5.2.2 Diameter Message Flows and Types 

The flows described in the present document specify the charging communications between IMS entities and the 
charging functions for different charging scenarios. The SIP messages associated with these charging scenarios are 
shown primarily for general information and to illustrate the charging triggers. They are not intended to be exhaustive 
of all the SIP message flows discussed in TS 24.228 [200]. 



5.2.2.1 



Message Flows - Successful Cases and Scenarios 



5.2.2.1.1 



Session Establishment - Mobile Origination 



The following figureshows the Diameter transactions that are required between CSCF and CDF during session 
establishment originated by a UE. 



Visited Network 



Home Network 



UE 



1. INVITE 




2. 200 OK 




P-CSCF 



CDF 

(visited) 



1. INVITE 



S-CSCF 



CDF 

(home) 



Service Control 



1. INVITE 



More SIP signalling 



^ 



200 OK (Invite) 



5. Accounting Requ 



2. 200 OK (Invite) 



Service Control 



St [Start] 



Open a P-CSCF CDR 



6. Accounting Answer 

K 



3. Accounting Request [Start] 




Open a S-CSCF CDR 



4. Accounting Answe: 

K 



More SIP signalling 




SIP Session established 



I I I I 

Figure : Message Sequence Chart for Session Establishment (Mobile Origination) 



1. 

2. 
3. 



4. 
5. 
6. 



The session is initiated. 

The destination party answers and a final response is received. 

Upon reception of the final response, the S-CSCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the S-CSCF CDR. 

The CDF acknowledges the reception of the data and opens a S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, but creating a P-CSCF CDR. 
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5.2.2.1.2 



Session Establishment - Mobile Termination 



The following figure shows the Diameter transactions that are required between CSCF and CDF during a session 
establishment that is terminated to a mobile. The I-CSCF is only involved in the INVITE transaction. 



Visited Network 



Home Network 



UE 



P-CSCF 




CDF 

(visited) 



S-CSCF 



CDF 

(liome) 



Cx Query with the HSS 



2. Accounting Request 



Create I-CSCF CDR 



Service Control 



3. Accounting Answer ^ 



More SIP signalling 



>. Accounting Reque^ [Start] 




Open P-CSCF CDR 



6. Accounting Answei 



7. Accounting Requ<^ t [Stai 



Open S-CSCF CDR 



i. Accounting Answe ■ 



More SIP signalling 



[Event] 





SIP Session established 



Figure : Message Sequence Chart for Session Establishiment (IVIobile Termination) 



1. 

2. 

3. 
4. 

5. ■ 



The session is initiated. 

Upon completing a Cx query the I-CSCF sends an Accounting Request with the 

Accounting-Record-Type set to EVENT. 

The CDF acknowledges the data received and creates an I-CSCF CDR. 

The destination party answers and a final response is sent. 

These steps are identical to the corresponding steps described in clause 5.2.2.1.1. 
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5.2.2.1.3 



Mid-Session Procedures 



The following figure shows the Diameter transactions that are required between CSCF and CDF when a UE generates a 
SIP (Re-)INVITE or SIP UPDATE in mid-session, e.g. in order to modify media component(s), or when the hold and 
resume procedure is executed. 



Visited Networlt 



Home Network 



CDF 

(visited) 



I 



CDF 

(iiome) 



SIP Session ongoing 



1. INVITE/ 
UPDATE 




1. INVITE/ 
UPDATE 



Service Control 



I. INVITE/ 
UPDATE 



More SIP signalling 



1. 200 OK (Invite/L pdate) 



2. 200 OK (Invite/Update) 



5. Accounting Requ 'st [Interim] 



2. 200 OK (Invite/U] idate) 



Service Control 



Update the P-CSCF CDR 



6. Accounting Answejr 



3. Accounting Request [Interim] 




Update the S-CSCE CDR 



4. Accounting Answer 



SIP Session continues 



Figure : Message Sequence Chart for Media Modification 



1. 

2. 
3. 



4. 
5. 
6. 



Modified media information is received from the subscriber. 

The destination party acknowledges the media modification. 

At modification of a media, the S-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating INTERIM_RECORD to record modification of a media component in the S-CSCF 

CDR. 

The CDF acknowledges the reception of the data and updates the S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, updating the P-CSCF CDR. 
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5.2.2.1.4 



Session Release - Mobile Initiated 



The following figure shows the Diameter transactions that are required between CSCF and CDF for a session release 
that is initiated by the UE. 



UE 



Visited Network 



fi. 200 OK 



P-CSCF 



CDF 

(visited) 



l.BYE 



2. Accounting Reque it [Stop] 



Close the P-CSCF CDR 



3. Accounting Answtr 



6. 200 OK 



Home Network 



S-CSCF 



CDF 

(home) 



Service Control 



l.BYE 



4. Accounting Reque it [Stop] 



Close the S-CSCF CDR 



^. Accounting 



AnsW' :r 



6. 200 OK 



Figure : Message Sequence Chart for Session Release 



1. 

2. 



3. 
4. 
5. 
6. 



The session is released. 

At session termination the P-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating STOP_RECORD to record stop of a session and stop of a media component in the 

P-CSCF CDR. 

The CDF acknowledges the reception of the data and closes the P-CSCF CDR. 

Same as 2, but for S-CSCF. 

Same as 3, closing the S-CSCF CDR. 

The release is acknowledged. 
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5.2.2.1.5 



Session-Unrelated Procedures 



The following figure shows the Diameter transactions that are required between CSCF and CDF for session-unrelated 
IMS procedures, i.e. those that relate to the Diameter ACR [Event], as listed in table 5.1. 



Visited Network 



Home Network 



UE 




P-CSCF 



1. SIP Request (e.g. 



2. SIP Response 



CDF 

(visited) 



SUBSCRIBE) 
I. SIP Request (e.g. 



S-CSCF 



SUBSCRIBE) 



CDF 

(home) 



Service Control 



More SIP signalling 



2. SIP Response 



5. Accounting Requt st [Event] 



Create P^CSCF CDR 



6. Accounting Answ ;r 



3. Accounting Reqt^ it [EvenI 




Create S-CSCF CDR 



4. Accounting Answ :r 



Figure : Message Sequence Chart for Session-Unrelated Procedure 



1. 

2. 



The P-CSCF receives a "SIP Request" (e.g. SUBSCRIBE) from the subscriber. 
The "SIP Request" is acknowledged by the "SIP Response" as follows: 

in the successful case, a 200 OK message is returned; 

in case of failure an appropriate SIP error message is returned. 



Depending on the used SIP method, there might be additional signalling between steps 1 and 2. 



3. 



4. 
5. 
6. 



After the completion of the procedure, the S-CSCF sends Accounting-Request with Accounting- 
Record-Type indicating EVENT_RECORD to record transaction specific information in the 
S-CSCF CDR. 

The CDF acknowledges the reception of the data and produces an S-CSCF CDR. 
Same as 3, but for P-CSCF. 
Same as 4, creating a P-CSCF CDR. 
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5.2.2.1.6 



Session Establishment - PSTN Initiated 



The following figure shows the Diameter transactions that are required between MGCF and CDF during session 
establishment initiated from the PSTN side. 



PSTN 



l.IAM 



4. ANM 



Home Network 



MGCF 



CDF 

(home) 



2. INVITE 



More SIP/ISUP signalling 



3. 200 OK (Invite) 



5. Accounting Request [Start] 



Open a MGCF CDR 



6. Accounting Answer 



More SIP signalling 



Session established 



Figure : Message Sequence Chart for Session Establishiment (PSTN Initiated) 

1 . The session is originated from the PSTN. 

2. The session setup is triggered in the IMS. 

3. The destination party answers and a final response is received. 

4. MGCF forwards an answer message to the PSTN. 

5. Upon reception of the final response, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of a media component 
in the MGCF CDR. 

6. The CDF acknowledges the reception of the data and opens a MGCF CDR. 
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5.2.2.1.7 



Session Establishment - IMS Initiated 



The following figure shows the Diameter transactions that are required between BGCF, MGCF and CDF during session 
establishment initiated from the IMS side. 



Home Network 




Figure : Message Sequence Chart for Session Establishment (IMS Initiated) 



1. 

2. 
3. 
4. 
5. 



6. 

7. 



The session is originated from the IMS. 

A session towards PSTN is established. 

The destination party answers and an answer message is received. 

A final response message is sent to the session originator. 

Upon reception of the answer message, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the MGCF CDR. 

The CDF acknowledges the reception of the data and opens a MGCF CDR. 

Upon reception of the 200 OK message, the BGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the BGCF CDR. 

The CDF acknowledges the reception of the data and opens a BGCF CDR. 
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5.2.2.1.8 



Session Release - PSTN Initiated 



The following figure shows the Diameter transactions that are required between BGCF, MGCF and CDF during a 
PSTN initiated session release. The BGCF is only involved if the session had been initiated from the IMS side. 



2. BYE 



Home Network 



BGCF 



MGCF 



CDF 



Session ongoing 



2. BYE 



6. Accounting Request [St )p] 



7. Accounting Answer 



l.REL 



3.RLC 



4. Accounting Request [Stop] 



PSTN 



Close the MGCF CDR 



^ 



. Accounting Answer 



Close BGCF CDR 



Figure : Message Sequence Chart for Session Release (PSTN initiated) 



1. 

2. 
3. 
4. 



5. 
6. 

7. 



The session release is initiated from PSTN. 

Session release continues within IMS. 

The reception of the release message is acknowledged. 

Upon reception of the release message, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating STOP_RECORD to record stop of a session in the MGCF 

CDR. 

The CDF acknowledges the reception of the data and closes the MGCF CDR. 

Same as 4, but for BGCF. 

Same as 5, but for BGCF. 
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5.2.2.1.9 



Session Release - IMS Initiated 



The following figure shows the Diameter transactions that are required between BGCF, MGCF and CDF during a IMS 
initiated session release. 

The BGCF is only involved if the session had been initiated from the IMS side. 

Home Network 



l.BYE 



1. 

2. 
3. 
4. 



5. 
6. 

7. 



BGCF 



MGCF 



CDF 



PSTN 



Session ongoing 



l.BYE 



4. Accounting Request [Sti 



'P] 



5. Accounting Answer 
< 



2. REL 



3.RLC 



Close BGCF CDR 



6. Accounting Request [Stop] 



Close the MGCF CDR 



J. Accounting Answer 



Figure : Message Sequence Chart for Session Release (IMS initiated) 

The session release is initiated from the IMS side. 

A release message is sent towards PSTN. 

The acknowledgement of the release message is received from PSTN. 

Upon reception of the BYE message, the BGCF sends ?in Accounting-Request with 

Accounting-Record-Type indicating STOP_RECORD to record stop of a session in the BGCF 

CDR. 

The CDF acknowledges the reception of the data and closes the BGCF CDR. 

Same as 4, but for MGCF. 

Same as 5, but for MGCF. 



5.2.2.1.10 



Multi-Party Call 



The following figure shows the establishment of an ad hoc conference (multiparty call). An AS (acting as B2BUA) 
performs third party call control with the MRFC, where the S-CSCF is in the signalling path. The Application Server 
that is in control of the ad hoc conference is aware of the MRFC capabilities. 

NOTE: Only accounting information sent from the MRFC is shown in detail in the figure. The SIP messages are 
for illustrative purpose only. 
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UE-1 



AS 



S-CSCF 



1. INVITE (MPTY) 



CDF 



t . INVITE (MPTY ) 



Service Logic 



MRFC 



2. INVITE (UE-2 S^P) 2. INVITE (UE-2 SDR) 



3. ^0OK(UE-2SD ^ ) 3. 200 OK (UE-2 SDR) 



UE-2 



4. A ccounting request [Start] 



Open MRFCCDR 



6. INVITE (UE-2 S^R) 

7. ^0OK(UE-2SD^) 



5. A ccounting Answer 

6. INVITE (UE-2 SDR) 



7. 200 OK (UE-2 SDR) 



8. ACK(UE-2SDR ^^ 8. ACK (UE-2 SDR) 



9. Accounting request [Interim] 
1^ 



Update MRFCCDR 



LACK (UE-2 SD^) 



10. Accounting Answe r 
11. ACK (UE-2 SDR) 



12 . INVITE (UE-3 ^DR) 12. INVITE (UE-3 SDR) 



13 .200OK(UE-3SDR ) 13. 200 OK (UE-3 SDR) 



14. INVITE (UE-3 SDR) 



14. INVITE (UE-3 SDR) 



15 . 200 OK (UE-3 Sl^) 

1 6 . ACK (UE-3 SDP) 1 6. ACK (UE-3 SDR) 



15. 200 OK (UE-3 SDR) 



17. Accounting request [Interim] 
1^ 



Update MRFCCDR 



1 8. Ac counting Ansv^^e r 



19 . ACK (UE-3 SD^) 



19. ACK (UE-3 SDR) 



20 . INVITE (UE-1 §DR) 

i ^i 



20. INVITE (UE-1 SDR) 



21 .200 OK (UE-1 Sl^) 21 . 200 OK (UE-1 SDR) 



22 . 200 OK (MRT^ 



23. 200 OK (MRTY) 



24 . ACK (UE-1 SD^) 24. ACK (UE-1 SDR) 




25. Accounting request [Interim] 



Update MRFCCDR 



26. Ac counting Answe r 



UE-3 




Figure : Message Sequence Chart for Multi-Party Call Establishment in MRFC 
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I. Sessions exist between UE-1 and UE-2, and between UE-1 and UE-3. A request is received from 
UE-lfor putting all parties together to a multi -party call. 

2.-3. Request and acknowledgement to initiate multi -party call. MRFC assigns a conference-ID that is 

used by the AS in subsequent interactions with the MRFC in INVITE messages connecting other 
endpoints (see TS 23.228 [201]). Path establishment between AS and MRFC for UE-2. 

4. At start of session establishment the MRFC sends an Accounting-Request with Accounting- 
Record-Type indicating START_RECORD to record start of multi-party call in the MRFC CDR 

5. The CDF acknowledges the reception of the data and creates the MRFC CDR. 'Calling Party 
Address', 'Service Request Time Stamp', 'Service ID' (holding the conference-ID) etc. are included 
in the MRFC CDR 

6-7. Path establishment between UE-2 and AS. Same ICID is used as for the path between AS and 

MRFC for UE-2 (step 2. - 3.). 
8 Acknowledgement of path between AS and MRFC for UE-2. 

9. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-2 has been connected to the multi-party call. 

10. The CDF acknowledges the reception of the data and includes UE-2 in the field 'Application 
Provided Called Parties' of the MRFC CDR. 

II. Acknowledgement of path between AS and UE-2. Now a path between UE-2 and MRFP via AS is 
established. 

Request and acknowledgement to establish path between AS and MRFC for UE-3. 
Path establishment between UE-3 and AS. Same ICID is used as for the path between AS and 
MRFC for UE-3 (step 12. - 13.). 

Acknowledgement of path between AS and MRFC for UE-3. 

The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-3 has been connected to the multi-party call. 

18. The CDF acknowledges the reception of the data and includes UE-3 in a new field 'Application 
Provided Called Parties' of the MRFC CDR. 

19. Acknowledgement of path between AS and UE-3. 
20-21. Request and acknowledgement to establish path between AS and MRFC for UE-1. Same ICID is 

used as for the path between UE-1 and AS (step 1.). 
22 - 23. Request for multi-party conference with UE-2 and UE-3 is acknowledged to UE 1. Implicit 

acknowledgement of path UE-1 to AS. 

24. Acknowledgement of path between AS and MRFC for UE-1. 

25. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-1 has been connected to the multi -party call. 

26. The CDF acknowledges the reception of the data and includes the field 'Service Delivery Start 
Time Stamp' into the MRFC CDR. 

27 -28. UE-1 acknowledges the multi -party call session establishment. 

NOTE: It is in the responsibility of the AS to terminate the sessions existing at the beginning of the multi-party 
call establishment between UE-1 and UE-2 and between UE-1 and UE-3 (see step 1.) in case of 
successful multi-party call establishment. This is not shown in the diagram above. 



12- 


-13. 


14. 


-15, 


16. 




17. 
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5.2.2.1.11 



AS Related Procedures - AS Acting as a Redirect Server 



Application servers may support a multitude of services which are not specified in 3GPP standards. Therefore it is not 
possible to standardise charging flows and procedures for those services. However, for all such services, the AS may 
apply either Event Charging, where ACR [Event] messages are generated, or Session Charging, using ACR [Start, Stop 
and Interim]. The following clauses depict one example for each of the two scenarios. The first procedure, AS acting as 
a Redirect Server, depicts the "event" case, while the second procedure, AS acting as a Voice Mail Server, depicts the 
"session" case. 

The following figure shows the case where an Application Server acts as a Redirect Server. In the figure below, UE-1 
sets up a session towards UE-2 but due to Call Forwarding functionality located in the AS, a new number (to UE-3) is 
returned to UE-1. Finally UE-1 sets up the session towards UE-3. 



Originating UE- 1 
home network 



Terminating UE-2 Home Network 



Terminating UE-3 
home network 



S-CSCF 



1. INVITE 



AS 



Service control 



6. 302 MOVED TEMPORARILY 



7. ACK 



, INVITE 



1. INVITE 



CDF 

(home) 



Application performs 
number translation 



2. 302 MOVED TEMPOR A.RILY 



3. ACK 



4. Accounting Request [Eve it] 



Create an AS CDR 



^ 



Accounting Answer 



Setting up session towards UE-3 



Figure : Message Sequence Chart for AS Acting as a Redirect Server 



1. 

2.-3. 
4. 



5. 
6-7. 



Sessions initiated by UE-1 towards UE-2. 

Response indicating that session should be redirected towards another number (UE-3). 

After successful service execution, the AS sends Accounting-Request with 

Accounting-Record-Type indicating EVENT_RECORD to record service specific information in 

the AS CDR. 

The CDF acknowledges the reception of the data and creates the AS CDR. 

Response indicating that session should be redirected towards another number (UE-3). 

Session is initiated by UE-1 towards UE-3. 



£75/ 



3GPP TS 32.260 version 6.0.0 Release 6 



27 



ETSI TS 132 260 V6.0.0 (2004-12) 



5.2.2.1.12 



AS Related Procedures - AS Acting as a Voice Mail Server 



The following figure shows the case where an Application Server acts as a Voice Mail Server. S-CSCF invokes the AS 
acting as Voice Mail Server according to procedure as defined in TS 23.218 [203]. 



S-CSCF 



AS (Voice 
Mail) 



CDF 



SIP signalling 



1. Invite 



Voice mail service invoked. 



2. 200 OK (Invite) 



3. Accounting Request [Start] 



Open an AS CDR 



4. Accounting Answer 



Voice mail session (playing announcements, etc.). . . When voice mail ends, tearing down session 



5. BYE 



6. Accounting Request [Stc p] 



Close the AS CDR 



7. Accounting Answer 



Figure : Message Sequence Chart for AS Acting as a IVIail Server 



1. 

2. 

3. 

4. 

5. 
6. 

7. 



AS receives the INVITE from the S-CSCF. 

AS acknowledges the initiated Voice Mail session by issuing a 200 OK in response to the 
INVITE. 

AS sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 
record start of a voice mail session. 

The CDF acknowledges the reception of the Accounting-Request with Accounting-Record-Type 
indicating START_RECORD and opens a AS CDR. 
Voice mail session release is initiated. 

Upon reception of release message AS sends an Accounting-Request with Accounting-Record- 
Type indicating STOP_RECORD to record stop of a session in the AS CDR. 
The CDF acknowledges the reception of the data and closes the AS CDR. 
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5.2.2.2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. The error cases are grouped into the 
following categories: 

• Failure in SIP Related Procedures; 

Session Related Error Scenarios; 
Session Unrelated Error Scenarios. 

• Errors in Diameter (Accounting) Related Procedures. 

5.2.2.2.1 Session Related SIP Procedures- Reception of SIP error messages 

A SIP session is closed abnormally by the reception of a BYE message indicating the reason for such termination. 
In this case, an ACR [Stop] message that includes an appropriate error indication is sent. 

5.2.2.2.2 Session Related SIP Procedures - SIP session failure 

All nodes involved in the SIP session are expected to exercise some kind of session supervision. In case a node detects 
an error in the SIP session, such as a timeout or the occurrence of an invalid SIP message that results in the inability to 
maintain the session, this IMS node will generate a BYE message towards both ends of the connection. 

The node that sent the BYE to trigger session termination identifies the cause of the failure in the ACR [Stop] towards 
the CDF. All other nodes, i.e. those that receive the BYE, are not aware of an error, and therefore they treat this 
situation as any normal SIP session termination. 

5.2.2.2.3 Session Unrelated SIP procedures 

As described in clause 5.1.2.1.2, a session unrelated SIP procedure may either be completed with the reception of a 
200OK, or a SIP error message. If the latter occurs, i.e. there is a failure in the procedure, the ACR [Event] sent towards 
the CDF includes an appropriate error indication. 

5.2.2.2.4 CDF Connection Failure 

When the connection towards the primary CDF is broken, the process of sending accounting information should 
continue towards a secondary CDF (if such a CDF is configured). For further CDF connection failure functionality, see 
clause "Transport Failure Detection" in [401]. 

If no CDF is reachable the network element may buffer the generated accounting data in non-volatile memory. Once the 
CDF connection is working again, all accounting messages stored in the buffer is sent to the CDF, in the order they 
were stored in the buffer. 

5.2.2.2.5 No Reply from CDF 

In case an IMS node does not receive an ACA in reply to an ACR, it may repeat the ACR message. The waiting time 
until a repetition is sent, and the maximum number of repetitions are both configurable by the operator. When the 
maximum number of repetitions is reached and still no ACA reply has been received, the IMS node executes the CDF 
connection failure procedure as specified above. 

If retransmitted ACRs are sent, they are marked with the T-flag as described in [401] , in order to allow duplicate 
detection in the CDF, as specified in the next clause. 

5.2.2.2.6 Duplicate Detection 

A Diameter client marks possible duplicate request messages (e.g. retransmission due to the link failover process) with 
the T-flag as described in [401]. 

If the CDF receives a message that is marked as retransmitted and this message was already received, then it discards 
the duplicate message. However, if the original of the re-transmitted message was not yet received, it is the information 
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in the marked message that is taken into account when generating the CDR. The CDRs are marked if information from 
duphcated message(s) is used. 

5.2.2.2.7 CDF Detected Failure 

The CDF closes a CDR when it detects that expected Diameter ACRs for a particular SIP session have not been 
received for a period of time. The exact behaviour of the CDF is operator configurable. 

5.2.3 CDR generation 

ffs 

5.2.4 GTP" record transfer flows 

GTP" is not used between CDF and CGF in IP Multimedia subsystem, because CDF and CGF are combined into CCF 
(see clause 4). 

Text should be copied from the middletear template section. 

5.2.5 Bi CDR file transfer 

ffs 



5.3 IMS Online Charging Scenarios 



5.3.1 Basic Principles 

IMS online charging uses the Credit Control application that is specified in 3GPP Rel-6 TS 32.299 [50]. 
Three cases for online charging are distinguished: 

• Immediate Event Charging (lEC); and 

• Event Charging with Unit Reservation (ECUR), and 

• Session Charging with Unit Reservation (SCUR) 

Both stage 2 and stage 3 mechanisms for the three cases for online charging are detailed in 3GPP Rel-6 TS 32.299 [50]. 

In the case of Immediate Event Charging (lEC), granting units to the IMS network element is performed in a single 
operation that also includes the deduction of the corresponding monetary units from the subscriber's account. The 
charging process is controlled by the corresponding credit control request which is sent for a given credit control event. 

In contrast. Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving, releasing 
and returning unused units for events. The deduction of the corresponding monetary units then occurs upon conclusion 
of the ECUR transaction. In this case, the credit control request is used to control the credit control session. 

Session Charging with Unit Reservation (SCUR) is used for credit control of sessions. SCUR also includes the process 
of requesting, reserving, releasing and returning unused units for sessions, and the deduction of the corresponding 
monetary units. During a SIP session there can be repeated execution of unit reservation and debit operations as 
specified in TS 32.299 [50]. 

The IMS network element may apply lEC, where CCR Event messages are generated, or ECUR, using CCR Initial, and 
Termination or SCUR. The decision whether to apply lEC, ECUR or SCUR is based on the service and/or operator's 
policy. 

NOTE: To the extent possible alignment with the IETF Credit Control Application, [402], is planned. However, 
this can only be accomplished when the current IETF draft receives an official RFC status. 
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5.3.2 Diameter Message Flows and Types 

This clause describes the message flows for the event charging procedures on the Ro interface. 

5.3.2.1 Immediate Event Charging (lEC) 

This clause provides the details of the "Debit Units" operation specified in TS 32.299 [50]. 

5.3.2.1 .1 Message Flows - Successful Cases and Scenarios 

5.3.2.1 .1 .1 lEC - Debit Units Operation 

The transactions that are required on the Ro interface in order to perform lEC with Debit Units operations are carried 
out as described in TS 32.299 [50] where 'CTF' refers to IMS network element. The Debit Units operation may 
alternatively be carried out prior to, concurrently with or after service/content delivery. The IMS network element must 
ensure that the requested service execution is successful, when this scenario is used. 

Editor" s Note: Must be ahgned with TS 32.299 [50]. 

5.3.2.1 .2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. 

The failure handling behaviour is locally configurable in the IMS network element. If the Direct-Debiting-Failure- 
Handling AVP is not used, the locally configured values are used instead. 

5.3.2.1 .2.1 Reception of SIP Error Messages 

If SIP errors in SIP response (4xx, 5xx or 6xx) occur during service delivery, as defined in TS 24.228 [202] and TS 
23.218 [203], it is up to the IMS network element to determine to what extent the service was delivered before the error 
occurred and act appropriately with respect to charging. This may imply that no units at all (or no more units) are 
debited. 

5.3.2.1 .2.2 Debit Units Operation Failure 

This case comprises situations where either no, or an erroneous response, is received from the ECF. The 'no response' 
case is detected by the IMS network element when the connection supervision timer Tx expires [402] before a response 
Credit-Control-Answer (CCA) is received. The case of receiving an erroneous response implies that the IMS network 
element receives a Credit-Control-Answer (CCA), which it is unable to process, while Tx is running. The failure 
handling complies with the failure procedures for "Direct Debiting" scenario described in [402]. 

5.3.2.1.2.3 Duplicate Detection 

The detection of duplicate request is needed and must be enabled. To speed up and simplify as much as possible the 
duplicate detection, the all-against-all record checking should be avoided and just those records marked as potential 
duplicates need to be checked against other received requests (within a reasonable time window) by the receiver entity. 

The IMS network element marks the request messages that are retransmitted after a link failover as possible duplicates 
with the T-flag as described in [201]. For optimized performance, uniqueness checking against other received requests 
is only necessary for those records marked with the T-flag received within a reasonable time window. This focused 
check is based on the inspection of the Session-Id and CC-Request-Number AVP pairs. 

5.3.2.2 Event Charging with Unit Reservation (ECUR) and Session Charging with 
Unit Reservation (SCUR) 

This clause provides the details of the "Reserve Units" and "Debit Units" operation specified in TS 32.299 [50]. 
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5.3.2.2.1 Message Flows - Successful Cases and Scenarios 

5.3.2.2.1 .1 ECUR and SCUR - Reserve Units and Debit Units Operations 

The transactions that are required on the Ro interface in order to perform ECUR/SCUR with Reserve Units and Debit 
Units operations is carried out as described in [32.299] where 'CTF' refers to an IMS network element. Multiple 
replications of both of these operations are possible. 

5.3.2.2.1.2 Expiration of Reservation Validity 

This clause defines how reserved units are returned, if not used, within a reasonable time. It should be possible that both 
the reservation and SIP sessions are cancelled or only the reservation is cancelled without removing the SIP session. 

5.3.2.2.2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. 

The failure handling behaviour is locally configurable in the IMS network element. If Credit-Control-Failure-Handling 
AVP is not used, the locally configured values are used instead. 

5.3.2.2.2.1 Reception of SIP Error Messages 

If SIP errors occur during service delivery, as defined in [202] and [203], it is up to the IMS network element to 
determine to what extent the service was delivered before the error occurred and act appropriately with respect to 
charging. This may imply that no units at all (or no more units) are reserved or debited. 

5.3.2.2.2.2 Reserve Units and Debit Units Operation Failure 

This case comprises of OCS connection failure, and/or receiving error responses from the OCS. 

The IMS network element detects an OCS connection failure when the timer Tx expires [402] or a transport failure is 
detected as defined in [401]. The OCS also has the capability to detect failures when the timer Ts [401] expires. The 
OCS should indicate the cause of failure by setting the appropriate result code as defined in [401] and [402]. In any 
case, the failure handling of IMS network element and OCS complies with the failure procedures for session based 
credit control scenario described in [402] . 

5.3.2.2.2.3 Duplicate Detection 

For credit control duplicate detection is performed only for possible duplicate event requests related to lEC as 
mentioned in clause 5.3.2. 1.2.3, as retransmission of ECUR/SCUR related credit control requests is not allowed. 
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6 Definition of charging information 

Charging Data Record Format Specifications (provide some introductory statement here) 

Equipment vendors shall be able to provide all of the parameters listed in the Diameter messages/CDR content table in 
order to claim compliance with the present document. However, since Diameter messages/CDR processing and 
transport consume network resources, operators may opt to eliminate some of the parameters that are not essential for 
their operation. This operator provisionable reduction is specified by the parameter category. 

A parameter category can have one of two primary values: 

M This parameter is Mandatory and shall always be present in the Diameter messages/CDR. 

C This parameter shall be present in the Diameter message/CDR only when certain Conditions are met. These 
Conditions are specified as part of the parameter definition. 

Some of these parameters are designated as Operator provisionable (O). Using TMN management functions or specific 
tools provided by an equipment vendor, operators may choose to include or omit the parameter from the charging 
event/CDR. Once omitted, this parameter is not generated in a CDR of the particular type.. To avoid any potential 
ambiguity, the CTF/CDF/CGF MUST be able to provide all these parameters. Only an operator can choose whether or 
not these parameters should be generated in its system, i.e. included in the charging Diameter message/CDR. 

Those parameters that the operator configures to be present or absent are further qualified with the "Operator 
provisionable" indicator as follows: 

Ojyj This is a parameter that, if provisioned by the operator to be present, shall always be included in the Diameter 
messages/CDRs. In other words, an Ojyj parameter that is provisioned to be present is a mandatory parameter. 

Oq This is a parameter that, if provisioned by the operator to be present, shall be included in the Diameter 

messages/CDRs when the specified conditions are met. In other words, an Oq parameter that is configured to 
be present is a conditional parameter. 

6.1 Data description for IMS offline charging 
6.1 .1 Diameter Message contents 



6.1.1.1 



Summary of Offline Charging Message Formats 



The IMS nodes generate accounting information that can be transferred from the nodes to the CDF. For this purpose, 
the IMS Charging application employs the Accounting-Request and Accounting-Answer messages from the base 
Diameter protocol. 

The table below describes the use of these messages for offline charging. 

Table : Offline Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Abbreviation 


Accounting-Request 


S-CSCF, l-CSCF, P-CSCF, MRFC, 
MGCF, BGCF, AS 


CDF 


ACR 


Accounting-Answer 


CDF 


S-CSCF, l-CSCF, P-CSCF, MRFC, 
MGCF, BGCF, AS 


ACA 



6.1.1.2 



Structure for the Accounting Message Formats 



IMS offline charging used the diameter accounting application with the two messages Accounting-Request and 
Accounting-Answer. The request can be of type start, stop, interim and event. The accounting request message includes 
all charging information and the answer is just an acknowledgement of the request message. Detailed information about 
the diameter offline charging application is described in TS 32.299 [50]. 
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This sub clause describes the different AVPs used in the accounting messages. 



6.1.1.2.1 



Accounting-Request Message 



The table below illustrates the basic structure of a Diameter Accounting-Request message as used for IMS offline 
charging. 

Table : Accounting-Request (ACR) Message Contents for Offline Charging 



AVP 


Category 


Description 


Provided by IMS 
NE 


Session-Id 


M 


Described in 32.299 [50] 


All 


Origin-Host 


M 


Described in 32.299 [50] 


All 


Origin-Realm 


M 


Described in 32.299 [50] 


All 


Destination- 
Realm 


M 


Described in 32.299 [50] 


All 


Accounting- 
Record-Type 


M 


Described in 32.299 [50] 


All 


Accounting- 
Record-Number 


M 


Described in 32.299 [50] 


All 


Acct-Application- 
Id 


Oc 


Described in 32.299 [50] 


All 


User-Name 


Oc 


Described in 32.299 [50] 


All 


Acct-lnterim- 
Interval 


Co 


Described in 32.299 [50] 


All 


Origin-State-Id 


Oc 


Described in 32.299 [50] 


All 


Event- 
Timestamp 


Oc 


Described in 32.299 [50] 


All 


Event-Type 


Oc 


This AVP holds the content of the "Event" header used in 
SUBSCRIBE and NOTIFY messages. 


All 


Role-of-node 


Oc 


This AVP specifies the role of the AS/CSCF 


All 


User-Session-ID 


Oc 


This AVP holds the session identifier. For a SIP session the 
Sess/on-/D contains the SIP Call ID. 


All 


Calling-Party- 
Address 


Oc 


This AVP holds the address (Public User ID: SIP URL, E.I 64, etc.) 
of the party initiating a session. 


All 


Called-Party- 
Address 


Oc 


This AVP holds the address (Public User ID: SIP URL, E.164, etc.) 
of the party to whom a session is established. 


All 


Time-stamp 


Oc 


This AVP holds the time of the initial SIP request and the time of the 
response to the initial SIP Request. 


All 


Application- 

Server- 

Information 


Oc 


This AVP holds the SIP URL(s) of the AS(s) addressed during the 
session and the called party number (SIP URL, E.164), if an 
application server determines it.. 


Only from S- 
CSCF/MRFC 


Inter-Operator- 
Identifier 


Oc 


This AVP holds the identification of the network neighbours 
(originating and terminating) as exchanged via SIP signalling. 


All 


llVIS-Charging- 
Identifier 


Oc 


This AVP holds the IMS Charging Identifier (ICID) as generated by a 
IMS node for a SIP session and described in clause 5.1 .2.2. 


All 


SDP-Session- 
Description 


Oc 


This AVP holds the content of an "attribute-line" (i=, c=, b=, k=, a=, 
etc.) related to a session. 


All 


SDP-Media- 
Components 


Oc 


This AVP contains information about media used for a IMS session. 


All 


GGSN-Address 


Oc 


This AVP holds the IP-address of the GGSN that generated the 
GPRS Charging ID, as described in [1]. 


All 


Served-Party-IP- 
Address 


Oc 


This AVP holds the IP address of either the calling or called party, 
depending on whether the P-CSCF is in touch with the calling or the 
called party. 


Only from P- 
CSCF 


Authorised-QoS 


Oc 


This AVP holds the Authorised QoS as defined in TS 23.207 / TS 
29.207 and applied via the Go interface. 


Only from P- 
CSCF 


Server- 
Capabilities 


Oc 


This AVP is described in 3GPP TS 29.229: "Cx and Dx Interfaces 
based on the Diameter protocol; Protocol Details". 


Only from 1- 
CSCF 


Trunk-Group-ID 


Oc 


This AVP identifies the incoming and outgoing PSTN legs. 


Only from MRFC 


Bearer-Service 


Oc 


This AVP holds the used bearer service for the PSTN leg. 


Only from MRFC 


Service-Id 


Oc 


This AVP identifies the service the MRFC is hosting. For 
conferences the conference ID is used as the value of this 
parameter. 


Only from MGCF 


UUS-Data 


Oc 


This AVP holds information about the sent User-To-User data. 


All 
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AVP 


Category 


Description 


Provided by IMS 
NE 


Cause 


Oc 


This AVP contains tlie cause value and the Node-Functionality AVP 
that contains the function of the node where the cause code was 
generated. 


All 



NOTE: For AVP of type "Grouped" only the group AVP is listed in table 6.2. Detailed descriptions of the AVPs 
are provided in TS 32.299 [50]. 



6.1.1.2.2 



Accounting-Answer Message 



The table below illustrates the basic structure of a Diameter Accounting- Answer message as used for IMS charging. 
This message is always used by the CDF as specified below, regardless of the IMS node it is received from and the 
ACR record type that is being replied to. 

Table : Accounting-Answer (ACA) Message Contents for Offline Charging 



AVP 


Category 


Description 


Session-Id 


M 


Described in 32.299 [50] 


Result-Code 


M 


Described in 32.299 [50] 


Origin-Host 


M 


Described in 32.299 [50] 


Origin-Realm 


M 


Described in 32.299 [50] 


Accounting-Record-Type 


M 


Described in 32.299 [50] 


Accounting-Record-Number 


M 


Described in 32.299 [50] 


Acct-Application-ld 


Oc 


Described in 32.299 [50] 


User-Name 


Oc 


Described in 32.299 [50] 


Acct-lnterim-lnterval 


Oc 


Described in 32.299 [50] 


Origin-State-Id 


Oc 


Described in 32.299 [50] 


Event-Timestamp 


Oc 


Described in 32.299 [50] 



Category in tables 6.2 and 6.3 shall use the categories according to 5.4 in 32.240. 

6.1 .1 .2.3 Detailed Message Formats 

The following table specifies per ACR type the accounting data that are sent by each of the IMS network elements: 

S-CSCF 

P-CSCF 

I-CSCF 

MRFC 

MGCF 

BGCF 

AS 

The ACR types in the table are listed in the following order: S (start)/I (interim)/S (stop)/E (event). Therefore, when all 
ACR types are possible it is marked as SISE. If only some ACR types are allowed for a node, only the appropriate 
letters are used (i.e. SIS or E) as indicated in the table heading. The omission of an ACR type for a particular AVP is 
marked with "-" (i.e. SI-E). Also, when an entire AVP is not allowed in a node the entire cell is marked as "-". 

Note that not for all Grouped AVPs the individual AVP members are listed in the table. Detailed descriptions of the 
AVPs are provided in TS 32.299 [50]. 

Table : Detailed Diameter ACR Message Contents for Offline Charging 
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AVP name 


Node Type 


S-CSCF 


P-CSCF 


l-CSCF 


MRFC 


MGCF 


BGCF 


AS 


Supported ACRs 


S/l/S/E 


S/l/S/E 


E 


S/l/S 


S/l/S/E 


S/l/S/E 


S/l/S/E 


AVPs from the Diameter base protocol 


<Session-ld> 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Origin-Host} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Origin-Realm} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Destination-Realm} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Accounting-Record-Type} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Accounting-Record-Number} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Vendor-Specific-Application-ld] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Acct-Application-ld] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[User-Name] (see note 1) 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Accounting-Sub-Session-Id] 


- 


- 


- 


- 


- 


- 


- 


[Accounting-RADIUS-Session-ld] 


- 


- 


- 


- 


- 


- 


- 


[Acct-Multi-Session-ld] 


- 


- 


- 


- 


- 


- 


- 


[Acct-lnterim-lnterval] 


SIS- 


SIS- 


- 


SIS- 


SIS- 


SIS- 


SIS- 


[Accounting-Realtime-Required] 


- 


- 


- 


- 


- 


- 


- 


[Origin-State-Id] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Event-Timestamp] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


*[Proxy-lnfo] 


- 


- 


- 


- 


- 


- 


- 


*[Route-Record] 


- 


- 


- 


- 


- 


- 


- 


*[AVP] 


- 


- 


- 


- 


- 


- 


- 


3GPP Diameter AVPs 


[Event-Type] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Role-of-Node] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[User-Session-Id] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Calling-Party-Address] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Called-Party-Address] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Time-stamps] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


*[Application-server-lnformation] (see note 1) 


SISE 


- 


- 


SIS 


- 


- 


- 


































[Inter-Operator-Identifiers] 
(see note 1) 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[llVIS-Charging-ldentifier] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


*[SDP-Session-Description] 


Sl- 


Sl- 


- 


Sl- 


Sl- 


Sl- 


Sl- 


*[SDP-Media-component] 


Sl- 


Sl- 




Sl- 


Sl- 


Sl- 


Sl- 


[GGSN-Address] 


Sl- 


Sl- 




Sl- 


Sl- 


Sl- 


Sl- 


[Served-Party-IP-Address] 
(see note 1) 


- 


SISE 


- 


- 


- 


- 


- 


[Authorized-OoS] (see note 1) 


- 


Sl- 


- 


- 


- 


- 


- 


[Server-Capabilities] 


- 


- 


E 


- 


- 


- 


- 


[Trunk-Group-ID] 


- 


- 


- 


- 


SISE 


- 


- 


[Bearer-Service] 


- 


- 


- 


- 


SISE 


- 


- 


[Service- Id] 


- 


- 


- 


SIS 


- 


- 


- 


[UUS-Data] (see note 2) 


SISE 


SISE 










SISE 


[Cause] 


-SE 


-SE 


E 


-s 


-SE 


-SE 


-SE 


NOTE 1 : Only present if available in the IMS node. 

NOTE 2: Present only if user-to-user data is included in the SIP message that triggered the ACR. 



6.1 .2 GTP" message contents 

GTP" is not used between CDF and CGF in IP Multimedia subsystem, because CDF and CGF are combined into CCF 

(see clause 4). 

Use text from middletear template 

6.1 .3 CDR Description on tine Bi Interface 
6.1.3.1 CDR Field Types 

The following Standard CDR content and format are considered: 
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S-CSCF-CDR generated based on information from the S-CSCF. 

I-CSCF-CDR generated based on information from the I-CSCF. 

P-CSCF-CDR generated based on information from the P-CSCF. 

BGCF-CDR generated based on information from the BGCF. 

MGCF-CDR generated based on information from the MGCF. 

MRFC-CDR generated based on information from the MRFC. 

AS-CDR generated based on information from the AS. 

The content of each CDR type is defined in the tables in clauses 6.1.3.3 to 6.1.3.9. For each CDR type the field 
definition includes the field name, category and description. The detailed field descriptions are provided in TS 32.298 
[51]. 

Editor" s Note: Equipment vendors shall be able to provide all of the fields listed in the CDR content table in order to 
claim compliance with the present document. However, since CDR processing and transport consume 
network resources, operators may opt to eliminate some of the fields that are not essential for their 
operation. 

Editors note: Rephrase the above paragraph and ref. to 32.240 

The CDF provides the CDRs at the Bi interface in the format and encoding described in TS 32.298 [51]. Additional 
CDR formats and contents may be available at the interface to the billing system to meet the requirements of the billing 
system, these are outside of the scope of 3GPP standardisation. 

6.1.3.2 CDR Triggers 

6.1.3.2.1 Session Related CDRs 

Reflecting the usage of multimedia sessions IMS CDRs are generated by the CDF on a per session level. In the scope of 
the present document the term "session" refers always to a SIP session. The coherent media components are reflected 
inside the session CDRs with a media component container comprising of all the information necessary for the 
description of a media component. 

Accounting information for SIP sessions is transferred from the IMS nodes involved in the session to the CDF using 
Diameter ACR Start, Interim and Stop messages. A session CDR is opened in the CDF upon reception of a Diameter 
ACR [Start] message. Partial CDRs may be generated upon reception of a Diameter ACR [Interim] message, which is 
sent by the network entity towards the CDF due to a session modification procedure (i.e. change in media). Session 
CDRs are updated, or partial CDRs are generated upon reception of a diameter ACR [Interim] message, which is sent 
by the network entity due to expiration of the Accounting-Interim-Interval AVP. The CDF closes the final session CDR 
upon reception of a Diameter ACR [Stop] message, which indicates that the SIP session is terminated. Further details 
on triggers for the generation of IMS CDRs are specified in [ 1 ] . 

Accounting information for unsuccessful session set-up attempts may be sent by the IMS node to the CDF employing 
the Diameter ACR [Event] message. The behaviour of the CDF upon receiving ACR [Event] messages is specified in 
clause 6.1.3.2.2. 

6.1.3.2.2 Session Unrelated CDRs 

To reflect chargeable events not directly related to a session the CDF may generate CDRs upon the occurrence of 
session unrelated SIP procedures, such as registration respectively de-registration events. Accounting information for 
SIP session-unrelated procedures is transferred from the IMS nodes involved in the procedure to the CDF using 
Diameter ACR [Event] messages. Session unrelated CDRs are created in the CDF in a "one-off action based on the 
information contained in the Diameter ACR [Event] message. One session unrelated CDR is created in the CDF for 
each Diameter ACR [Event] message received, whereas the creation of partial CDRs is not applicable for session 
unrelated CDRs. The cases for which the IMS nodes send ACR [Event] messages are listed per SIP procedure in 
tables 5.1 and 5.2. 

Further details on triggers for the generation of IMS CDRs are specified in clause 5.2.2. 
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6.1 .3.3 S-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 
Table : Charging Data of S-CSCF CDR 
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Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Origin-Host MP 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Diameter 
ACRs has been used in this CDR 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. This parameter corresponds to SIP-Event-Type AVP 


Role of Node 


Om 


This field indicates the role of the AS/CSCF. This parameter corresponds to Role-of- 
Node AVP 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. This parameter corresponds to the Of/g/n-Hosf AVP 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. This parameter 
corresponds to User-Session-ID AVP 


Calling Party Address 


Om 


The address (Public User ID) of the party requesting a service or initiating a session. 
This field holds either the SIP URL (according to IETF RFC 3261 [404]) or the TEL 
URL (according to RFC 2806 [403]) of the calling party. This parameter corresponds 
to Calling-Party-Address AVP 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. This parameter 
corresponds to Called-Party-Address AVP 


Private User ID 


Om 


Holds the used Network Access Identifier of the served party according to RFC2486 
[405]. This parameter corresponds to the User-Name AVP 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. This parameter corresponds to SIP-Request-Timestamp AVP in START 
ACR 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. This parameter corresponds to SIP-Response-Timestamp AVP in 
START ACR 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. This parameter corresponds to SIP-Request- 
Timestamp AVP in STOP ACR 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CCF opened this record. Present only in SIP 
session related case 


Record Closure Time 


Om 


A Time stamp reflecting the time the CCF closed the record 


Application Servers 
Information 


Oc 


This a grouped CDR field containing the fields: 'Application Server Involved' and 
'Application Provided Called Parties' 


Application Servers 
Involved 


Oc 


Holds the ASs (if any) identified by the SIP URLs. This parameter corresponds to 
Application-Server AVP 


Application Provided 
Called Parties 


Oc 


Holds a list of the Called Party Address(es), if the address(es) are determined by an 
AS (SIP URL, E.164...). This parameter corresponds to Application-Provided-Called- 
Party-Address AVP 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the Inter-Operator-Identifier IKMP 


Originating 101 


Oc 


This parameter corresponds to Originating-IOI AVP 


Terminating 101 


Oc 


This parameter corresponds to Terminating-IOI AVP 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CCF 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CCF for a particular session 


Cause For Record 
Closing 


Om 


This field contains a reason for the release of the CDR 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CCF detects missing ACRs 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. This parameter corresponds to IMS-Charging-ldentifier (ICID) 
AVP 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. This parameter corresponds to SDP-Session- 
Description AVP 


List of SDP Media 
Components 


Oc 


This is a grouped field comprising several sub-fields associated with one media 
component. It may occur several times in one CDR. The field is present only in a SIP 
session related case 
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Field 


Category 


Description 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP-Request-Timestamp AVP in INTERIM ACR 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 200 
OK). This parameter corresponds to SIP-Response-Timestamp AVP in INTERIM 
ACR 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. This parameter corresponds to SDP- 
Media-Component AVP 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Name 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Description 


GPRS Charging ID 


Om 


This parameter holds the GPRS charging ID (GCID) which is generated by the GGSN 
for a GPRS PDP context. This parameter corresponds to GPRS-Charging-ld 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of a IMS session. This parameter corresponds to GGSN- 
Address AVP 


Service Delivery 
Failure Reason 


Oc 


Holds the reason for why a requested service could not be successfully provided (i.e. 
SIP error codes taken from SIP-Method AVP). This field is not present in case of a 
successful service delivery 


List of Message 
Bodies 


Oc 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message bodies 
may be exchanged via SIP-signalling, this grouped field may occur several times. 
This parameter corresponds to UUS-Data AVP 


Content-Type 


Oc 


This sub-field of Message Bodies holds the MIME type of the message body, 
Examples are: application/zip, image/gif, audio/mpeg, etc. This parameter 
corresponds to UUS-Data AVP/Mime-Type AVP or Event-Type AVP/ Content-Type 
AVP 


Content-Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the message body 
inside the SIP signalling, Content-disposition header field equal to 'render', indicates 
that 'the body part should be displayed or otherwise rendered to the user'. Content 
disposition values are: session, render, inline, icon, alert, attachment, etc. This 
parameter corresponds to Even-Type AVP / Content-Disposition AVP 


Content-Length 


Oc 


This sub-field of Message Bodies holds the size of the data of a message body in 
bytes. This parameter corresponds to UUS-Data AVP/ Amount-of-UUS-data AVP or 
Event-Type AVP / Content-Length AVP 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the originating party of the 
message body. This parameter corresponds to UUS-Data AVP/ Direction AVP 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension 



6.1 .3.4 P-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 
Table : Charging Data of P-CSCF CDR 
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Field 


Category 


Description 


Record Type 


M 


Identifies tfie type of record. The parameter is derived from the Origin-Host MP 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Diameter 
ACRs has been used in this CDR 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. This parameter corresponds to SIP-Event-Type AVP 


Role of Node 


Om 


This fields indicates the role of the AS/CSCF. This parameter corresponds to Role-of- 
Node AVP 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. This parameter corresponds to the Of/g/n-Hosf AVP 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. This parameter 
corresponds to User-Session-ID AVP 


Calling Party Address 


Om 


The address (Public User ID) of the party requesting a service or initiating a session. 
This field holds either the SIP URL (according to IETF RFC 3261 [404]) or the TEL 
URL (according to RFC 2806 [403]) of the calling party. This parameter corresponds 
to Calling-Party-Address AVP 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. This parameter 
corresponds to Called-Party-Address AVP 


Served Party IP 
Address 


Om 


This field contains the IP address of either the calling or called party, depending on 
whether the P-CSCF is in touch with the calling or called network. This parameter 
corresponds to Served-Party-IP-Address AVP 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. This parameter corresponds to SIP-Request-Timestamp AVP in START 
ACR 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. This parameter corresponds to SIP-Response-Timestamp AVP in 
START ACR 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. This parameter corresponds to SIP-Request- 
Timestamp AVP in STOP ACR 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CCF opened this record. Present only in SIP 
session related case 


Record Closure Time 


Om 


A Time stamp reflecting the time the CCF closed the record 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the Inter-Operator-Identifier IKMP 


Originating 101 


Oc 


This parameter corresponds to Originating-IOI AVP 


Terminating 101 


Oc 


This parameter corresponds to Terminating-IOI AVP 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CCF 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CCF for a particular session 


Cause For Record 
Closing 


Om 


This field contains a reason for the release of the CDR 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CCF detects missing ACRs 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. This parameter corresponds to IMS-Charging-ldentifier (ICID) 
AVP 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. This parameter corresponds to SDP-Session- 
Description AVP 


List of SDP Media 
Components 


Oc 


This is a grouped field comprising several sub-fields associated with one media 
component. It may occur several times in one CDR. The field is present only in a SIP 
session related case 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP-Request-Timestamp AVP in INTERIM ACR 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 200 
OK). This parameter corresponds to SIP-Response-Timestamp AVP in INTERIM 
ACR 
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Field 


Category 


Description 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. This parameter corresponds to SDP- 
Media-Component AVP 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Name 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Description 


GPRS Charging ID 


Om 


This parameter holds the GPRS charging ID (GCID) which is generated by the GGSN 
for a GPRS PDP context. This parameter corresponds to GPRS-Charging-ld AVP 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party 


Authorised QoS 


Oc 


Authorised QoS as defined in TS 23.207 [7] / TS 29.207 [8] and applied via the Go 
interface. This parameter corresponds to Authorised-QoS AVP 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of a IMS session. This parameter corresponds to GGSN- 
Address AVP 


Service Delivery 
Failure Reason 


Oc 


Holds the reason for why a requested service could not be successfully provided (i.e. 
SIP error codes taken from SIP-Method AVP). This field is not present in case of a 
successful service delivery 


List of Message 
Bodies 


Oc 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message bodies 
may be exchanged via SIP-signalling, this grouped field may occur several times. 
This parameter corresponds to UUS-Data AVP 


Content-Type 


Oc 


This sub-field of Message Bodies holds the MIME type of the message body, 
Examples are: application/zip, image/gif, audio/mpeg, etc. This parameter 
corresponds to UUS-Data AVP/Mime-Type AVP or Event-Type AVP/ Content-Type 
AVP 


Content-Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the message body 
inside the SIP signalling, Content-disposition header field equal to 'render', indicates 
that 'the body part should be displayed or otherwise rendered to the user'. Content 
disposition values are: session, render, inline, icon, alert, attachment, etc. This 
parameter corresponds to Even-Type AVP / Content-Disposition AVP 


Content-Length 


Oc 


This sub-field of Message Bodies holds the size of the data of a message body in 
bytes. This parameter corresponds to UUS-Data AVP/ Amount-of-UUS-data AVP or 
Event-Type AVP / Content-Length AVP 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the originating party of the 
message body. This parameter corresponds to UUS-Data AVP/ Direction AVP 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension 



6.1.3.5 l-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 
Table : Charging Data of I-CSCF CDR 
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Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Origin-Host MP 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Diameter 
ACRs has been used in this CDR 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. This parameter corresponds to SIP-Event-Type AVP 


Role of Node 


Om 


This fields indicates the role of the AS/CSCF. This parameter corresponds to Role-of- 
Node AVP 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. This parameter corresponds to the Of/g/n-Hosf AVP 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. This parameter 
corresponds to User-Session-ID AVP 


Calling Party Address 


Om 


The address (Public User ID) of the party requesting a service or initiating a session. 
This field holds either the SIP URL (according to IETF RFC 3261 [404]) or the TEL 
URL (according to RFC 2806 [403]) of the calling party. This parameter corresponds 
to Calling-Party-Address AVP 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. This parameter 
corresponds to Called-Party-Address AVP 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. This parameter corresponds to SIP-Request-Timestamp AVP in START 
ACR 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the Inter-Operator-Identifier IKMP 


Originating 101 


Oc 


This parameter corresponds to Originating-IOI AVP 


Terminating 101 


Oc 


This parameter corresponds to Terminating-IOI AVP 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CCF 


Cause For Record 
Closing 


Om 


This field contains a reason for the release of the CDR 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CCF detects missing ACRs 


S-CSCF Information 


Oc 


This field contains Information related to the serving CSCF, e.g. the S-CSCF 
capabilities upon registration event or the S-CSCF address upon the session 
establishment event 


IMS Charging 
Identifier 


Mo 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. This parameter corresponds to IMS-Charging-ldentifier (ICID) 
AVP 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of a IMS session. This parameter corresponds to GGSN- 
Address AVP 


Service Delivery 
Failure Reason 


Oc 


Holds the reason for why a requested service could not be successfully provided (i.e. 
SIP error codes taken from SIP-Method k\IP). This field is not present in case of a 
successful service delivery 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension 



6.1.3.6 M RFC CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 
Table 6 : Charging Data of MRFC CDR 
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Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Origin-Host MP 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Diameter 
ACRs has been used in this CDR 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. This parameter corresponds to SIP-Event-Type AVP 


Role of Node 


Om 


This fields indicates the role of the AS/CSCF. This parameter corresponds to Role-of- 
Node AVP 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. This parameter corresponds to the Of/g/n-Hosf AVP 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. This parameter 
corresponds to User-Session-ID AVP 


Service ID 


Om 


This field identifies the service the MRFC is hosting. For conferences the conference 
ID is used here. This parameter corresponds to Service-Id AVP 


Calling Party Address 


Om 


The address (Public User ID) of the party requesting a service or initiating a session. 
This field holds either the SIP URL (according to lb 1 h RFC 3261 [404]) or the TEL 
URL (according to RFC 2806 [403]) of the calling party. This parameter corresponds 
to Calling-Party-Address AVP 


Called Party Address 


Oc 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. This parameter to 
corresponds Called-Party-Address AVP 


Service Request 
Time Stamp 


Om 


This field contains the time stamp which indicates the time at which the service was 
requested. This parameter corresponds to SIP-Request-Timestamp AVP in START 
ACR 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. This parameter corresponds to SIP-Response-Timestamp AVP in 
START ACR 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. This parameter corresponds to SIP-Request- 
Timestamp AVP in STOP ACR 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CCF opened this record. Present only in SIP 
session related case 


Record Closure Time 


Om 


A Time stamp reflecting the time the CCF closed the record 


Application Servers 
Information 


Oc 


This a grouped CDR field containing the fields: 'Application Server Involved' and 
'Application Provided Called Parties' 


Application Servers 
Involved 


Oc 


Holds the ASs (if any) identified by the SIP URLs. This parameter corresponds to 
Application-Server AVP 


Application Provided 
Called Parties 


Oc 


Holds a list of the Called Party Address(es), if the address(es) are determined by an 
AS (SIP URL, E.164...). This parameter corresponds to Application-Provided-Called- 
Party-Address AVP 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the Inter-Operator-Identifier IKMP 


Originating 101 


Oc 


This parameter corresponds to Originating-IOI AVP 


Terminating 101 


Oc 


This parameter corresponds to Terminating-IOI AVP 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CCF 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CCF for a particular session 


Cause For Record 
Closing 


Om 


This field contains a reason for the release of the CDR 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CCF detects missing ACRs 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. This parameter corresponds to IMS-Charging-ldentifier (ICID 
AVP 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. This parameter corresponds to SDP-Session- 
Description AVP 


List of SDP Media 
Components 


Oc 


This is a grouped field comprising several sub-fields associated with one media 
component. It may occur several times in one CDR. The field is present only in a SIP 
session related case 
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Field 


Category 


Description 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP-Request-Timestamp AVP in INTERM ACR 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 200 
OK). This parameter corresponds to SIP-Response-Timestamp AVP in INTERM ACR 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. This parameter corresponds to SDP- 
Media-Component AVP 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Name 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Description 


GPRS Charging ID 


Om 


This parameter holds the GPRS charging ID (GCID) which is generated by the GGSN 
for a GPRS PDP context. This parameter corresponds to GPRS-Charging-ld AVP 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of a IMS session. This parameter corresponds to GGSN- 
Address AVP 


Service Delivery 
Failure Reason 


Oc 


Holds the reason for why a requested service could not be successfully provided (i.e. 
SIP error codes taken from SIP-Method AMP). This field is not present in case of a 
successful service delivery 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension 



6.1.3.7 MGCF CD R Content 

The detailed description of the field is provided in TS 32.298 [51]. 
Table : Charging Data of MGCF CDR 
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Field 


Category 


Description 


Record Type 


M 


Identifies tfie type of record. The parameter is derived from the Origin-Host MP 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Diameter 
ACRs has been used in this CDR 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. This parameter corresponds to SIP-Event-Type AVP 


Role of Node 


Om 


This fields indicates the role of the AS/CSCF. This parameter corresponds to Role-of- 
Node AVP 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. This parameter corresponds to the Of/g/n-Hosf AVP 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. This parameter 
corresponds to User-Session-ID AVP 


Calling Party Address 


Om 


The address (Public User ID) of the party requesting a service or initiating a session. 
This field holds either the SIP URL (according to IETF RFC 3261 [404]) or the TEL 
URL (according to RFC 2806 [403]) of the calling party. This parameter corresponds 
to Calling-Party-Address AVP 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. This parameter to 
corresponds Called-Party-Address AVP 


Service Request 
Time Stamp 


Om 


This field contains the time stamp which indicates the time at which the service was 
requested. This parameter corresponds to SIP-Request-Timestamp AVP in START 
ACR 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. This parameter corresponds to SIP-Response-Timestamp AVP in 
START ACR 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. This parameter corresponds to SIP-Request- 
Timestamp AVP in STOP ACR 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CCF opened this record. Present only in SIP 
session related case 


Record Closure Time 


Om 


A Time stamp reflecting the time the CCF closed the record 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the Inter-Operator-Identifier A\/P 


Originating 101 


Oc 


This parameter corresponds to Originating-IOI AVP 


Terminating 101 


Oc 


This parameter corresponds to Terminating-IOI AVP 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CCF 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CCF for a particular session 


Cause For Record 
Closing 


Om 


This field contains a reason for the release of the CDR 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CCF detects missing ACRs 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. This parameter corresponds to IMS-Charging-ldentifier (ICID) 
AVP 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. This parameter corresponds to SDP-Session- 
Description AVP 


List of SDP Media 
Components 


Oc 


This is a grouped field comprising several sub-fields associated with one media 
component. It may occur several times in one CDR. The field is present only in a SIP 
session related case 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP-Request-Timestamp AVP in INTERM ACR 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 200 
OK). This parameter corresponds to SIP-Response-Timestamp AVP in INTERM ACR 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. This parameter corresponds to SDP- 
Media-Component AVP 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Name 
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Field 


Category 


Description 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Description 


GPRS Charging ID 


Om 


This parameter holds the GPRS charging ID (GGID) which is generated by the GGSN 
for a GPRS PDP context. This parameter corresponds to GPRS-Charging-ld AVP 


IVIedia Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of a IMS session. This parameter corresponds to GGSN- 
Address AVP 


Service Delivery 
Failure Reason 


Oc 


Holds the reason for why a requested service could not be successfully provided (i.e. 
SIP error codes taken from SIP-Method AVP). This field is not present in case of a 
successful service delivery 


Trunk Group ID 
Incoming/Outgoing 


Om 


Contains the outgoing trunk group ID for an outgoing session/call or the incoming 
trunk group ID for an incoming session/call. This parameter corresponds to Trunk- 
Group-ID AVP 


Bearer Service 


Om 


Holds the used bearer service for the PSTN leg. This parameter corresponds to 
Bearer-Service AVP 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension 



6.1.3.8 BGCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 
Table : Charging Data of BGCF CDR 
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Field 


Category 


Description 


Record Type 


M 


Identifies tfie type of record. The parameter is derived from the Origin-Host MP 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Diameter 
ACRs has been used in this CDR 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. This parameter corresponds to SIP-Event-Type AVP 


Role of Node 


Om 


This fields indicates the role of the AS/CSCF. This parameter corresponds to Role-of- 
Node AVP 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. This parameter corresponds to the Of/g/n-Hosf AVP 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. This parameter 
corresponds to User-Session-ID AVP 


Calling Party Address 


Om 


The address (Public User ID) of the party requesting a service or initiating a session. 
This field holds either the SIP URL (according to IETF RFC 3261 [404]) or the TEL 
URL (according to RFC 2806 [403]) of the calling party. This parameter corresponds 
to Calling-Party-Address AVP 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. This parameter 
corresponds to Called-Party-Address AVP 


Service Request 
Time Stamp 


Om 


This field contains the time stamp which indicates the time at which the service was 
requested. This parameter corresponds to SIP-Request-Timestamp AVP in START 
ACR 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. This parameter corresponds to SIP-Response-Timestamp AVP in 
START ACR 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. This parameter corresponds to SIP-Request- 
Timestamp AVP in STOP ACR 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CCF opened this record. Present only in SIP 
session related case 


Record Closure Time 


Om 


A Time stamp reflecting the time the CCF closed the record 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the Inter-Operator-Identifier A\/P 


Originating 101 


Oc 


This parameter corresponds to Originating-IOI AVP 


Terminating 101 


Oc 


This parameter corresponds to Terminating-IOI AVP 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CCF 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CCF for a particular session 


Cause For Record 
Closing 


Om 


This field contains a reason for the release of the CDR 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CCF detects missing ACRs 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. This parameter corresponds to IMS-Charging-ldentifier (ICID) 
AVP 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. This parameter corresponds to SDP-Session- 
Description AVP 


List of SDP Media 
Components 


Oc 


This is a grouped field comprising several sub-fields associated with one media 
component. It may occur several times in one CDR. The field is present only in a SIP 
session related case 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP-Request-Timestamp AVP in INTERM ACR 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 200 
OK). This parameter corresponds to SIP-Response-Timestamp AVP in INTERM ACR 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. This parameter corresponds to SDP- 
Media-Component AVP 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Name 
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Field 


Category 


Description 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Description 


GPRS Charging ID 


Om 


This parameter holds the GPRS charging ID (GGID) which is generated by the GGSN 
for a GPRS PDP context. This parameter corresponds to GPRS-Charging-ld AVP 


IVIedia Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of a IMS session. This parameter corresponds to GGSN- 
Address AVP 


Service Delivery 
Failure Reason 


Oc 


Holds the reason for why a requested service could not be successfully provided (i.e. 
SIP error codes taken from SIP-Method k\IP). This field is not present in case of a 
successful service delivery 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension 



6.1.3.9 SIP AS CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 
Table : Charging Data of AS CDR 
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Field 


Category 


Description 


Record Type 


M 


Identifies tfie type of record. The parameter is derived from the Origin-Host MP 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Diameter 
ACRs has been used in this CDR 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. This parameter corresponds to SIP-Event-Type AVP 


Role of Node 


Om 


This fields indicates the role of the AS/CSCF. This parameter corresponds to Role-of- 
Node AVP 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. This parameter corresponds to the Of/g/n-Hosf AVP 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. This parameter 
corresponds to User-Session-ID AVP 


Calling Party Address 


Om 


The address (Public User ID) of the party requesting a service or initiating a session. 
This field holds either the SIP URL (according to IETF RFC 3261 [404]) or the TEL 
URL (according to RFC 2806 [403]) of the calling party. This parameter corresponds 
to Calling-Party-Address AVP 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. This parameter 
corresponds to Called-Party-Address AVP 


Service Request 
Time Stamp 


Om 


This field contains the time stamp which indicates the time at which the service was 
requested. This parameter corresponds to SIP-Request-Timestamp AVP in START 
ACR 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. This parameter corresponds to SIP-Response-Timestamp AVP in 
START ACR 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. This parameter corresponds to SIP-Request- 
Timestamp AVP in STOP ACR 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CCF opened this record. Present only in SIP 
session related case 


Record Closure Time 


Om 


A Time stamp reflecting the time the CCF closed the record 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the Inter-Operator-Identifier A\/P 


Originating 101 


Oc 


This parameter corresponds to Originating-IOI AVP 


Terminating 101 


Oc 


This parameter corresponds to Terminating-IOI AVP 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CCF 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CCF for a particular session 


Cause For Record 
Closing 


Om 


This field contains a reason for the release of the CDR 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CCF detects missing ACRs 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. This parameter corresponds to IMS-Charging-ldentifier (ICID) 
AVP 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. This parameter corresponds to SDP-Session- 
Description AVP 


List of SDP Media 
Components 


Oc 


This is a grouped field comprising several sub-fields associated with one media 
component. It may occur several times in one CDR. The field is present only in a SIP 
session related case 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP-Request-Timestamp AVP in INTERM ACR 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 200 
OK). This parameter corresponds to SIP-Response-Timestamp AVP in INTERM ACR 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. This parameter corresponds to SDP- 
Media-Component AVP 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Name 
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Field 


Category 


Description 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Description 


GPRS Charging ID 


Om 


This parameter holds the GPRS charging ID (GCID) which is generated by the GGSN 
for a GPRS PDP context. This parameter corresponds to GPRS-Charging-ld AVP 


IVIedia Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of a IMS session. This parameter corresponds to GGSN- 
Address AVP 


Service Delivery 
Failure Reason 


Oc 


Holds the reason for why a requested service could not be successfully provided (i.e. 
SIP error codes taken from SIP-Method A\/P). This field is not present in case of a 
successful service delivery 


Service Specific Data 


Oc 


This field contains service specific data 


List of IVlessage 
Bodies 


Oc 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message bodies 
may be exchanged via SIP-signalling, this grouped field may occur several times 


Content-Type 


Oc 


This sub-field of Message Bodies holds the MIME type of the message body, 
Examples are: application/zip, image/gif, audio/mpeg, etc. This parameter 
corresponds to UUS-Data AVP/Mime-Type AVP or Event-Type AVP/ Content-Type 


Content-Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the message body 
inside the SIP signalling, Content-disposition header field equal to 'render', indicates 
that 'the body part should be displayed or otherwise rendered to the user'. Content 
disposition values are: session, render, inline, icon, alert, attachment, etc. This 
parameter corresponds to Even-Type AVP / Content-Disposition AVP 


Content-Length 


Oc 


This sub-field of Message Bodies holds the size of the data of a message body in 
bytes. This parameter corresponds to UUS-Data AVP/ Amount-of-UUS-data AVP or 
Event-Type AVP / Content-Length AVP 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the originating party of the 
message body. This parameter corresponds to UUS-Data AVP/ Direction AVP 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension 



6.2 Data description for IIVIS online charging 
6.2.1 Diameter message contents 



6.2.1.1 



Summary of Online Charging Message Formats 



IMS Online Charging uses the Credit-Control-Request (CCR) and Credit-Control- Answer (CCA) messages defined in 
TS 32.299 [50]. 

The following table describes the use of these messages for online charging. 

Table : Online Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Abbreviation 


Credit-Control-Request 


MRFC, AS, 
IMS-GWF 


OCS 


CCR 


Credit-Control-Answer 


OCS 


MRFC, AS, 
IMS-GWF 


CCA 
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6.2.1.2 



Structure for the Credit Control Message Formats 



IMS online charging uses the diameter credit control application with the two messages Credit-Control-Request (CCR) 
and Credit-Control-Answer (CCA). The request performs rating of the IMS service and reserves units on the users 
account. The answer replies back with amount of reserved units or an error code if the user is out of credit. Detailed 
information about the diameter online charging application is described in TS 32.299 [50]. 

This sub clause describes the different AVPs used in the credit control messages. 

Editors Note: The IMS specific AVPs should be put in the Service Information AVP 

The CCR types in the table are listed in the following order: I (initial)/ U (update)/ T (terminate)/E (event). Therefore, 
when all CCR types are possible it is marked as lUTE. If only some CCR types are allowed for a node, only the 
appropriate letters are used (i.e. lUT or E) as indicated in the table heading. The omission of a CCR type for a particular 
AVP is marked with "-" (i.e. lU-E). Also, when an entire AVP is not allowed in a node the entire cell is marked as "-". 

Note that not for all Grouped AVPs the individual AVP members are listed in the table. Detailed descriptions of the 
AVPs are provided in TS 32.299 [50]. 



6.2.1.2.1 



MRFC Credit-Control-Request Message 



The following table illustrates the basic structure of a Diameter credit control request message from MRFC as used for 
IMS online charging. 

Table : Credit-Control-Request (CCR) Message Contents for MRFC 



AVP 


Category 


Description 


Type 


Session-Id 


M 


Described in 32.299 [50] 


lUTE 


Origin-Host 


M 


Described in 32.299 [50] 


lUTE 


Origin-Realm 


M 


Described in 32.299 [50] 


lUTE 


Destination-Realm 


M 


Described in 32.299 [50] 


lUTE 


Auth-Application-ld 


M 


Described in 32.299 [50] 


lUTE 


Destination-Host 


Oc 


Described in 32.299 [50] 


lUTE 


User-Name 


Oc 


Described in 32.299 [50] 


lUTE 


Origin-State-Id 


Oc 


Described in 32.299 [50] 


lUTE 


Event-Tlmestamp 


Oc 


Described in 32.299 [50] 


lUTE 


CC-Request-Type 


M 


Described in 32.299 [50] 


lUTE 


CC-Request-Number 


M 


Described in 32.299 [50] 


lUTE 


CC-Subsession-ld 


? 


Described in 32.299 [50] 


- 


Subscription-Id 


Oc 


Described in 32.299 [50] 


lUTE 


Requested-Action 


Oc 


Described in 32.299 [50] 


-E 


Requested-Service-Unit 


Oc 


Described in 32.299 [50] 


lU-E 


Used-Service-Unit 


Oc 


Described in 32.299 [50] 


-UT- 


Service-Parameter-Info 


Oc 


Described in 32.299 [50] 


lUTE 


CC-Correlation-ld 


Oc 


Described in 32.299 [50] 


lUTE 


Service-Identifier 


? 


Described in 32.299 [50] 


???? 


Service-Context 


? 


Described in 32.299 [50] 


???? 


IVIultiple-Services-lndicator 


? 


Described in 32.299 [50] 


- 


IVIultiple-Services-Credit Control 


? 


Described in 32.299 [50] 


- 


Route-Record 


C 


Described in 32.299 [50] 


lUTE 


AVP 


Oc 


Described in 32.299 [50] 


lUTE 


llVIS-lnformation 


Oc 


Described in clause 6.2.2 


lUTE 



The full description of the AVPs is specified in TS 32.299 [50]. 



6.2.1.2.2 



AS Credit-Control-Request Message 



The following table illustrates the basic structure of a Diameter credit control request message from Application Server 
as used for IMS online charging. 

Table : Credit-Control-Request (CCR) Message Contents for AS 
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AVP 


Category 


Description 


Type 


Session-Id 


M 


Described in 32.299 [50] 


lUTE 


Origin-Host 


M 


Described in 32.299 [50] 


lUTE 


Origin-Realm 


M 


Described in 32.299 [50] 


lUTE 


Destination-Realm 


M 


Described in 32.299 [50] 


lUTE 


Auth-Application-ld 


M 


Described in 32.299 [50] 


lUTE 


Destination-Host 


Oc 


Described in 32.299 [50] 


lUTE 


User-Name 


Oc 


Described in 32.299 [50] 


lUTE 


Origin-State-Id 


Oc 


Described in 32.299 [50] 


lUTE 


Event-Tlmestamp 


Oc 


Described in 32.299 [50] 


lUTE 


CC-Request-Type 


M 


Described in 32.299 [50] 


lUTE 


CC-Request-Number 


M 


Described in 32.299 [50] 


lUTE 


CC-Subsession-ld 


? 


Described in 32.299 [50] 


- 


Subscription-Id 


Oc 


Described in 32.299 [50] 


lUTE 


Requested-Action 


Oc 


Described in 32.299 [50] 


— E 


Requested-Service-Unit 


Oc 


Described in 32.299 [50] 


lU-E 


Used-Service-Unit 


Oc 


Described in 32.299 [50] 


-UT- 


Service-Parameter-Info 


Oc 


Described in 32.299 [50] 


lUTE 


CC-Correlation-ld 


Oc 


Described in 32.299 [50] 


lUTE 


Service-Identifier 


? 


Described in 32.299 [50] 


???? 


IVIultiple-Services-lndicator 


? 


Described in 32.299 [50] 


- 


IVIultiple-Services-Credit Control 


? 


Described in 32.299 [50] 


- 


Route-Record 


C 


Described in 32.299 [50] 


lUTE 


AVP 


Oc 


Described in 32.299 [50] 


lUTE 


IMS-Information 


Oc 


Described in clause 6.2.2 


lUTE 



The full description of the AVPs for IMS is specified in TS 32.299 [50]. 



6.2.1.2.3 



IMS Gateway Credit-Control Message 



The following table illustrates the basic structure of a Diameter credit control request message from IMS Gateway as 
used for IMS online charging. 

Table : Credit-Control-Request (CCR) Message Contents for IMS-GWF 



AVP 


Category 


Description 


Type 


Session-Id 


M 


Described in 32.299 [50] 


lUTE 


Origin-Host 


M 


Described in 32.299 [50] 


lUTE 


Origin-Realm 


M 


Described in 32.299 [50] 


lUTE 


Destination-Realm 


M 


Described in 32.299 [50] 


lUTE 


Auth-Application-ld 


M 


Described in 32.299 [50] 


lUTE 


Destination-Host 


Oc 


Described in 32.299 [50] 


lUTE 


User-Name 


Oc 


Described in 32.299 [50] 


lUTE 


Origin-State-Id 


Oc 


Described in 32.299 [50] 


lUTE 


Termination-Cause 


Oc 


Described in 32.299 [50] 


lUTE 


Event-Timestamp 


Oc 


Described in 32.299 [50] 


lUTE 


CC-Request-Type 


M 


Described in 32.299 [50] 


lUTE 


CC-Request-Number 


M 


Described in 32.299 [50] 


- 


CC-Subsession-ld 


Oc 


Described in 32.299 [50] 


lUTE 


Subscription-Id 


Oc 


Described in 32.299 [50] 


— E 


Requested-Action 


Oc 


Described in 32.299 [50] 


lU-E 


Requested-Service-Unit 


Oc 


Described in 32.299 [50] 


-UT- 


Used-Service-Unit 


Oc 


Described in 32.299 [50] 


lUTE 


Service-Parameter-Info 


Oc 


Described in 32.299 [50] 


lUTE 


CC-Correlation-ld 


Oc 


Described in 32.299 [50] 


lUTE 


Service-Identifier 


? 


Described in 32.299 [50] 


- 


IVIultiple-Services-lndicator 


? 


Described in 32.299 [50] 


- 


Multiple-Services-Credit Control 


? 


Described in 32.299 [50] 


- 


Route-Record 


C 


Described in 32.299 [50] 


lUTE 


AVP 


Oc 


Described in 32.299 [50] 


lUTE 


IMS-Information 


Oc 


Described in clause 6.2.2 


lUTE 
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The full description of the AVPs for IMS is specified in TS 32.299 [50]. 



6.2.1.2.4 



Credit-Control-Answer Message 



The following table illustrates the basic structure of a Diameter credit control answer message as used for IMS 
charging. This message is always used by the OCS as specified below, independent of the receiving IMS node and the 
CCR request type that is being replied to. 

Editors Note: rework the table to include which network elements use which parameters. 

Table : Credit-Control- Answer (CCA) Message Contents for MRFC, AS and IMS-GWF 



AVP 


Category 


Description 


Type 


Session-Id 


M 


Described in 32.299 [50] 


lUTE 


Result-Code 


M 


Described in 32.299 [50] 


lUTE 


Origin-Host 


M 


Described in 32.299 [50] 


lUTE 


Origin-Realm 


M 


Described in 32.299 [50] 


lUTE 


Auth-Application-ld 


M 


Described in 32.299 [50] 


lUTE 


User-Name 


Oc 


Described in 32.299 [50] 


lUTE 


Origin-State-id 


Oc 


Described in 32.299 [50] 


lUTE 


Event-Timestamp 


Oc 


Described in 32.299 [50] 


lUTE 


CC-Request-Type 


M 


Described in 32.299 [50] 


lUTE 


CC-Request-Number 


M 


Described in 32.299 [50] 


lUTE 


CC-Subsession-ld 


? 


Described in 32.299 [50] 


- 


Subscription-Id 


Oc 


Described in 32.299 [50] 


lUTE 


Tariff-Switch-Definition 


9 


Described in 32.299 [50] 


- 


Cost-Information 


Oc 


Described in 32.299 [50] 


lUTE 


Final-Unit-lndication 


Oc 


Described in 32.299 [50] 


lUTE 


Check-Balance-Result 


Oc 


Described in 32.299 [50] 


lUTE 


Credit-Control-Failure-Handling 


Oc 


Described in 32.299 [50] 


lU- 


Validity-Time 


Oc 


Described in 32.299 [50] 


lU- 


Direct-Debiting-Failure-Handling 


? 


Described in 32.299 [50] 


- 


Multiple-Services-Credit Control 


? 


Described in 32.299 [50] 


- 
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6.2.2 AVPs for IMS Online Charging on the Ro interface 

The IMS Information AVP used for IMS online charging is provided in the Service-Information AVP. 

The use of the Attribute Value Pairs (AVPs) that are defined is available in the Diameter application specification TS 
32.299 [50]. 

6.2.2.1 Definition of the IMS-Information AVP 

The detailed structure of the IMS -Information AVP can be found in the following table. 

The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 
'V, indicates whether the optional Vendor-ID field is present in the AVP header. 

Table : Structure of the IMS -Information AVP 











AVP Flag rules 


AVP Name 


AVP Code 


Defined 


Value Type 


Must 


May 


Should not 


Must not 


[Event-Type] 


823 


[501 


Grouped 










[SIP-Method] 


824 


[501 


UTF8String 










[Event] 


825 


[50] 


UTF8String 










[Content-Type] 


826 


[50] 


UTF8String 










[Content-Length] 


827 


[50] 


UTF8String 










[Content-Disposition] 


828 


[50] 


UTF8String 










[Role-of-Node] 


829 


[50] 


Enumerated 










[User Session Id] 


830 


[50] 


UTF8String 










[Calling-Party-Address] 


831 


[50] 


UTF8String 










[Called-Party-Address] 


832 


[50] 


UTF8String 










[Time-stamps] 


833 


[50] 


Grouped 










[SIP-Request-Timestamp] 


834 


[50] 


UTF8String 










[SIP-Response-Timestamp] 


835 


[50] 


UTF8String 










[Application-server-lnformation] 


863 


[50] 


Grouped 










[Application-server] 


836 


[50] 


UTF8String 










*[Application-provided-called-party-address] 


837 


[50] 


UTF8String 










*[lnter-Operator-ldentifier] 


838 


[50] 


Grouped 










[Originating-IOI] 


839 


[50] 


UTF8String 










[Terminating-IOI] 


840 


[50] 


UTF8String 










[IMS-Charging-ldentifier] 


841 


[50] 


UTF8String 










*[SDP-Session-Description] 


842 


[50] 


UTF8String 










*[SDP-Media-component] 


843 


[50] 


Grouped 










[SDP-Media-Name] 


844 


[50] 


UTF8String 










*[SDP-Media-Description] 


845 


[50] 


UTF8String 










[GPRS-Charging-ld] 


846 


[50] 


UTF8String 










[GGSN-Address] 


847 


[50] 


IPAddress 










[Served-Party-IP-Address] 


848 


[50] 


IPAddress 










[Authorized-QoS] 


849 


[50] 


UTF8String 










[Server-Capabilities] 


[19] 


[50] 












[Trunk-Group-Id] 


851 


[50] 


Grouped 










[Incoming-Trunk-Group-Id] 


852 


[50] 


UTF8String 










[Outgoing-Trunk-Group-Id] 


853 


[50] 


UTF8String 










[Bearer-Service] 


854 


[50] 


OctetString 










[Service-Id] 


855 


[50] 


UTF8String 










[UUS-Data] 


856 


[50] 


Grouped 










[Amount-of-UUS-data] 


857 


[50] 


UTF8String 










[Mime-type] 


858 


[50] 


UTF8String 










[Direction] 


859 


[50] 


Enumerated 










[Cause] 


860 


[50] 


Grouped 










{Cause-Code} 


861 


[50] 


Enumerated 










{Node-Functionality} 


862 


[50] 


Enumerated 
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Annex A (informative): 
Application Charging ID 

Editors note: Subject for further review. 



A.1 Charging correlation procedures for presence 

For presence service, ICID is not sufficient for correlation information for presence charging because ICID is used only 
to correlate IMS session level with bearer level for IMS basic PS services. In realese 6, non SIP protocol such as XCAP 
for Ut interface shall also trigger to generate the ICID for charging purposes. Besides that in rel6, new services such as 
presence, conference, etc is coming up where ICID is not enough correlation information any more. 

Since presence service is involved with the other SIP requests triggered by Presence server or Resource list server, new 
ACID (Application Charging ID) shall be generated apart from ICID during presence related SIP/non SIP requests. 

The ACID is used for correlation between the multiple session related or session unrelated dialog for watcher and the 
session related or session unrelated dialog for the presentities. Because these multiple set of dialogs shares the related 
charging data records so that these shall be treaded as one package for charging purposes. 

The ACID is generated at the first entity which decides the SIP/non SIP request as presence service or conference 
service. Note that in case when the combined presence and conference services are occurred, for example, first initiated 
ACID triggered by either of service is used entirely until all involved dialogs are terminated. 

A.1 .1 Subscription for presence event notification 

When S-CSCF receives SUBSCRIBE from the watcher, S-CSCF shall check event header in SUBSCRIBE and shall 
generate ACID if event header is set to " presence". S-CSCF shall insert the ACID to P- Application Charging- Vector 
header of SUBSCRIBE when S-CSCF sends SUBSCRIBE to presence server. The presence server shall insert ACID to 
200 OK when the presence server sends 200 OK to the watcher. 

A.1 .2 Subscription for his own resource list 

When S-CSCF receives SUBSCRIBE from the watcher, S-CSCF shall check event header in SUBSCRIBE and shall 
generate ACID if event header is set to " presence". S-CSCF shall insert the ACID to P-Service Charging-Vector 
header of SUBSCRIBE when S-CSCF sends SUBSCRIBE to resource list server. The resource list server shall insert 
ACID to 200 OK when the resource list server sends 200 OK to the watcher. 

A.1 .3 RLS subscription to presentities 

When RLS sends SUBSCRIBE to presence server belonging to presentities, RLS shall insert ACID into P- Application 
Charging-Vector header of SUBSCRIBE saved locally when SUBSCRIBE is received from the watcher. In case when 
RLS has to send multiple SUBSCRIBE to presentities, the same SCID shall be inserted into SUBSCRIBE to each 
presentity. 

A.1 .4 Updating of presence information by UE 

When S-CSCF receives PUBLISH from the presentity, S-CSCF shall check ACID saved locally for the presentity 
S-CSCF shall insert the ACID to P-Service Charging-Vector header of PUBLISH when S-CSCF sends PUBLISH to 
presence server. The presence server shall insert the SCID to 200 OK when the presence server sends 200 OK to the 
presentity. 
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A.1 .5 PS notifying watcher of updates to presence information 

When PS sends NOTIFY to watcher, PS shall insert ACID into NOTIFY saved locally when SUBSCRIBE is received 
from the watcher. 

A.1 .6 PS notifying resource list server and watcher of updates to 
presence information 

When PS sends NOTIFY to RLS, PS shall insert ACID into P-Service Charging- Vector header of NOTIFY saved 
locally when SUBSCRIBE is received from the watcher. In case when RLS has to send multiple NOTIFY to watchers, 
the same ACID shall be inserted into NOTIFY to each watcher. 

A.1 .7 Generation of ICID for non SIP request 

For the presence service, on receiving the non SIP request (ex. XCAP for Ut interface) at P-CSCF or on initiating the 
non SIP request at AS, ICID shall be generated and inserted into the relevant xml parameter of message and sent to the 
next entities. 



A.2 Charging correlation procedures for Conference 

Since conference service is involved with multi-party sessions triggered by Focus or other participants, ACID shall be 
also generated apart from ICID during conference related SIP/non SIP requests. ACID is used for correlation between 
the session related or session unrelated dialog for participants. Because these set of dialogs share the related charging 
data records so that these shall be treaded as one package for charging purposes in later use. The ACID is generated at 
the first entity which decides the SIP/non SIP requests as conference service. The ACID is also used for presence or 
other service. 

Note that in case when the combined presence and conference services are occurred , for example, first initiated ACID 
triggered by either of service is used entirely until all involved dialogs are terminated. 

A.2.1 Joining a conference using the conference URI - dial in 

When S-CSCF receives INVITE from participant, S-CSCF shall check conference URI in INVITE and shall generate 
ACID if present. S-CSCF shall insert the ACID to P-Service-Charging ID- Vector of INVITE when S-CSCF sends 
INVITE to Focus. Focus shall insert ACID to 200 OK when Focus sends 200 OK to the participant. 

A.2. 2 Adding a participant by the Focus - dial out 

When Focus initiates INVITE to participant, the Focus shall generate ACID and shall insert the ACID to P-Service- 
Charging ID-Vector of INVITE when the Focus sends INVITE to the participant. 

A.2. 3 Manually creating a conference by dialling into conferencing 
application 

When a conference server application receives INVITE from participant, the application requests additional input from 
participant before it is able to create a conference. After focus is created, when the focus initiates INVITE to 
participant, the Focus shall generate ACID and shall insert the generated ACID to P-Service-Charging ID- Vector of 
INVITE when the Focus sends INVITE to the participant. 
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A.2.4 Creating a Conference by conference-unaware UA 

In this case, participant creates the conference URI ( using some convention agreed to with the focus domain) and sends 
an INVITE to that URI which creates the focus. When S-CSCF receives INVITE from participant, S-CSCF shall check 
conference URI in INVITE and shall generate ACID if present. S-CSCF shall insert the generated ACID to P-Service- 
Charging ID-Vector of INVITE when S-CSCF sends INVITE to Focus. Focus shall insert ACID to 200 OK when Focus 
sends 200 OK to participant. 

A.2.5 Creating a Conference using Ad-Hoc SIP methods 

In this case, the conference factory URI is used to automatically create the conference. The SIP URI of the conference 
factory is provided with preconfigured data in UA. Initial INVITE from participant is sent to conference factory for 
creating the focus. The conference factory applications send back a 302 Moved temporally response with the 
conference URI generated at conference factory. After receiving 302 Moved temporally, participant sends INVITE to 
the focus. W hen S-CSCF receives INVITE from participant, S-CSCF shall check conference URI in INVITE and shall 
generate ACID if present. S-CSCF shall insert the ACID to P-Service-Charging ID-Vector of INVITE when S-CSCF 
sends INVITE to the focus. 

A.2.6 Requesting the Focus to add a new resource to a 
conference 

When the S-CSCF receives REFER from participants, S-CSCF shall insert the ACID saved locally for this session, and 
send REFER to S-CSCF and Focus. When the Focus initiates INVITE to new participant, the Focus shall insert the said 
ACID which is received from S-CSCF to INVITE when the Focus sends INVITE to new participant. 

A.2.7 Adding a 3"^^ party using conference URI 

When the S-CSCF receives REFER from participants, S-CSCF shall insert the ACID saved locally for this session, and 
send REFER to new participant. When the new participant initiates INVITE to the Focus, the Focus shall insert the said 
ACID received from S-CSCF to INVITE when the Focus sends INVITE to new participant. 

A.2.8 Adding a 3^^ party using dialog identifier 

When the Focus receives JOIN with dialogue identifier from new participants, the Focus shall insert the ACID saved 
locally for the session related to this dialog identifier, and send 200 OK to new participant. 

A.2.9 Changing user agents within a conference 

When the Focus receives REPLACE with dialogue identifier from new UA, but the same participants, the Focus shall 
insert the ACID saved locally for the session related to this dialog identifier, and send 200 OK to new participant. 

A.2.1 Bringing a point to point dialog into a conference 

Focus shall send re -INVITE with a different conference URI and the ACID saved locally for the session related to this 
dialog identifier to the requesting participant. 

A.2.1 1 Generation of ICID for non SIP request 

For the conference service, on receiving the non SIP request (ex. XCAP for Ut interface) at P-CSCF or on initiating the 
non SIP request at AS, ICID shall be generated and inserted into the relevant XML parameter of message and sent to 
the next entities. 
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